One of the often untapped pieces of extreme value in VersionOne is the ability to easily track Issues.  VersionOne provides teams a central place to track issues at the Project and Team levels.  This allows teams, no matter how distributed, to collaborate closely on those things that are keeping the project from moving forward.

This post isn’t going to teach you the basics of using Issues in VersionOne; if you want to learn more about that, I highly recommend checking out the our VTV production video on Issues.

This blog will give you 5 clever and handy ways that any team could use Issues in VersionOne:

Use #1:  Identify Impediments. Simply defined, something that is hindering or obstructing progress. Usually captured by a team member, but could start impacting the entire team. Every team has regular issues such as “Development Environment Crashed” or “Production Change Control didn’t approve necessary firewall rules.” VersionOne makes it really easy to capture impediments as they occur. By blocking items in the Backlog, everyone has visibility and can lend a hand or idea to help.

Use #2:  Monitor Third-Party Dependencies. A common question I get is, “How can we manage deliveries from another team?” Well, first I would have a Backlog item (Story) surrounding the delivery and assign it to the appropriate person for verifying and/or integrating the solution. Second, I would create an Issue with estimated delivery date entered into the Target Date field. As with the Story, set the Owner on the Issue. The Story should be placed and managed in the Backlog based on the expected delivery (usually based on urgency) and possible dependencies. You can do one of two things as far as blocking the Story… Go ahead and block it right away so it is very visible to the team that, in order for the Story to be finished, we are waiting on another party. Or, block the Story on the day the Target Date is reached and the delivery is not in the door. One important note about the term “Third Party…” This can include external or internal teams responsible for delivering something required for the project.

Use #3:  Manage Risk. During the various agile planning levels, it’s a good practice to assess risks — risks either to the team or to the project/product. During planning sessions, we generally identify the risks and calculate the threat based on the likelihood of there becoming an issue, and the impact if it did. Capturing the risks in VersionOne as Issues provides project visibility; a team can create Stories (Generate Backlog Item) from the risk, which would help mitigate the threat. If the risk does escalate, it can be used to block the impacted Stories.

Use #4:  Identify Engineering Challenges. To some people, this is a defect or a bug found during the development, testing and/or verification of a story. I like to call it an Engineering Challenge or Development Issue. While a Story is being worked on — since we are discovering more about the implementation (or how) while we build it — it doesn’t make sense to declare that we found a defect. The challenge could be a new idea, a missing piece of information, an item that is still work-in-progress, or something which another engineer found before we handed it off to the customer. This approach allows the team to put up the red flag and it becomes a “promise for a conversation.” I prefer to have one issue that is re-used for this purpose; this allows the team to easily identify active Engineering Challenges.

Use #5:  Retrospective Issues. During retrospectives, the team will identify new ideas that are usually captured as Stories. Sometimes they capture things that are basically in everyone’s crawl. Otherwise, issues that come up during a retrospective which are more process- and/or team-related, and as a team, need to be tracked and remedied. These could be as simple as, “We don’t have a Team Space for our Information Radiator.” Capturing these and putting them in as issues provides the transparency and visibility for the stakeholders so they can help ensure resolution.

For all of these Issue uses, I recommended leveraging the Issue Type field and customizing it. By doing so, it is easy to filter and report on issues. A team can also build a Custom Report and or Dashboard that could be displayed on a large screen in the team space, giving real-time visibility to those items that are challenging the team.