One question that we’ve been asked frequently is, “How do I handle Investment Themes?”  Investment Themes represent company initiatives and are comprised of several epics.

A custom drop-down on the epic asset provides a useful way to capture an epic’s investment theme.  The drop-down will be available as a filter, so people who care about a particular investment theme can filter the Epicboard and Epic Tree pages.  As for reporting, VersionOne Analytics automatically supports custom drop-downs.  Portfolio Managers can easily ask questions like, “How much time are we allocating across each of our Investment Themes?”

Let us know how this approach works for you!

The VersionOne Winter ’12 Release brings with it the ability to drag and drop within the epic tree to both rank and manage the hierarchical relationships. As a product owner, this is already making my life much easier.

See how it works…

Learn more more about drag & drop epic ranking in VersionOne.

Working in VersionOne back at my computer, I thought about how the spokes are a great metaphor for one of the unsung hero features of VersionOne, that being Links.  In VersionOne every asset has a set of relationships that can be set up between assets within VersionOne. For instance, a story has relationships with its tasks and acceptance tests.  VersionOne also provides the ability to establish relationships with external artifacts that support an agile software development project.  The most useful feature for doing this is Links.

Links in VersionOne allow the customer to associate any artifact that can be referenced by a URL to an asset within VersionOne.  This is a great fit for the emergent design nature of agile software development.  Designs emerge as more conversations and collaboration occurs.  These collaborations often produce artifacts that further the understanding of design, be it architectural design, user interface design, test design, algorithm design or whatever.  Often these artifacts are captured and shared in tools other than VersionOne which makes sense because VersionOne is a project planning and management tool, not a word processor or a diagramming tool or a graphics tool.

Links allow VersionOne to be the hub of the project wheel.  It connects those on a project to a common set of artifacts that can be referenced when project team members collaborate to further a design or to solve a problem.

Within VersionOne, Links can be accessed in the details dialog of each asset.  The details dialog for an asset is brought up simply by clicking on the asset title (name).  A shortcut to getting at an asset’s Links or to add new Links is to simply hover over the title of an asset and a popup will appear as shown below.

Notice the second icon at the top right of the popup.  It looks like two chain links.  If you click on this icon, the Link dialog will open and allow you to access the Links for the asset you’ve chosen, or allow you to create new Links as you can see from the image of the Links dialog shown below.

So, don’t forget about the VersionOne Links feature.  It allows you to keep your artifacts in the system of record you like — on a Wiki or in Sharepoint, for instance — to link the artifacts to the project hub. The Links feature supports the weight of understanding in the same way that my bike’s spokes support my weight when I’m riding.

Once you set up your template backlog item/story you can add tasks to it (Product Planning –> Templates).   Your tasks should represent characteristics of the work to be completed that is repeatable.  You may need different templates to represent various types of work you are completing.



Each template could represent a common feature type (reports, service, Web page, etc.) and the common tasks that are part of completing that specific work.

Once the templates are created, you can use the “Plan Backlog Item” option (available on most views from the Action menu). Use the “Copy Tasks and Tests” feature to list the templates and their tasks/tests with an option to copy all or select individual ones.

These tasks can also be there ahead of time if Product Owners generate backlog items from templates that have tasks and tests.   The tasks and tests are also copied to the new item.

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.

But don’t get me wrong… VersionOne product demos are not for everyone.  To help you figure out where you stand, I’ve put together these 5 Signs That a VersionOne Product Demo is NOT right for you.

Please do NOT attend our live product demo if:

1. You detest people who really get agile. Our expert Product Specialists will provide pragmatic answers to your questions and help you understand how agile development can be applied in your environment.
2. You like to stay myopic and suboptimize around what matters only to you. We’ll touch on all of the key roles in the agile software development process, so you have the big picture of how the entire agile development team can be successful in VersionOne.
3. You get annoyed by learning new things. Many experienced users who attend a second time are surprised by how much they learn.
4. You like to learn the hard way. Why spend a single hour, when you could spend several hours trying to figure it out on your own?
5. You stayed at a Holiday Inn Express last night. We can’t beat that, try as we might.

Already a VersionOne super user?  Be a good friend and forward this post to someone who would benefit, or register your team!

How to most appropriately Epics or Feature Groups was also a question I had when I was a new VersionOne user.  Having worked through that question myself, and then having had the opportunity to work with many teams experiencing the same dilemma, I suggest making the distinction between Epics and Feature Groups in terms of two attributes: (1) Type of Information Represented and (2) Lifetime.

Type of Information Represented

Typically, an Epic is used to represent some specific capability that consists of smaller Backlog items which can be implemented independently.  The Epic can be viewed as a single capability by stakeholders, if that’s their preference, and it provides cohesion between those smaller, independent Backlog items that roll up into it.  For example, stakeholders might see “Manage Account” as a capability, and may be interested in tracking it at that level.  As the Product Owner and Team look at this in terms of how it can be implemented, however, they might break this down into smaller Backlog items such as “Create Account,” “Update Account,” “Archive Account,” “Generate Account Summary Report” and so on.

A Feature Group (or ‘Theme’), by comparison, usually represents a category of functionality, rather than some specific capability.  Using the example above, the first three Backlog items might be associated with the “Account Management” Feature Group. “Generate Account Summary Report” might be in the “Reporting” Feature Group:

Lifetime

If an Epic is being used to represent some specific capability, all of its constituent Backlog items will be completed at some point, so eventually we can close the Epic in VersionOne (the action taken to signify that we’re done and we’re moving on).  Meanwhile, the product lives on.  In other words, the lifetime of an Epic in VersionOne is typically shorter than the lifetime of the product.

A Feature Group’s lifetime is most often equal to the life of the product because it’s being used to define a category, rather than a specific capability.  A product’s “Account Management” Feature Group, for example, might be used to identify Backlog items pertaining to account management, and that Feature Group could then be used for filtering and reporting.  Throughout the life of the product, account management-related Backlog items will be completed and closed, and new ones created. But the “Account Management” Feature Group will remain alive as long as that category of functionality remains part of the product.

Another important note is that since the lifetime of a product will normally include many releases, and since an Epic’s constituent Backlog items may be implemented over a series of releases, both Feature Groups and Epics can span Projects in VersionOne.  The image above illustrates this.

Recapping then,

• An Epic is typically used to represent a specific capability that’s comprised of smaller features which can be implemented independently, and its lifetime is shorter than the life of the product
• A Feature Group is typically used to represent a category of capabilities, and its lifetime is usually equal to the life of the product

I use the word “typically” here because this is how organizations normally use these two assets.  Bear in mind though that Epics and Feature Groups are simply means of organizing information; you may find other uses for them as you continuously adapt the way you work for the better.

How are you using Epics and Feature Groups in your organization?

Implementing VersionOne Ideas takes a little foresight.  What would compel a busy user to spend the time to submit an idea?

One of our customers, Sage Software, answered this question in the following way:

• Different organizations within the company reinforce that VersionOne Ideas is the place to capture feedback.  When talking with customers, both Sales and Customer Support educate customers on the usage of VersionOne Ideas as the place to cast their votes for what should get into the software.
• VersionOne Ideas is integrated into Sage’s product survey, which is integrated into their product.  At regular intervals, the product asks users if they would like to take a short survey.  At the end of the survey, VersionOne Ideas is offered as a forum for submitting specific feature suggestions.
• VersionOne Ideas is integrated into the Sage product.  By following a navigation path from within the product, users are able to provide feedback without having to remember how to get there.

None of these approaches is particularly difficult to implement.  They result in users knowing about VersionOne Ideas and having easy access to it, so they share feedback.  For Sage, the entire organization gets both qualitative feedback (the comments) and quantitative feedback (the votes), which helps product management understand customer demand.  Less time is spent reaching consensus on customer demand, and product management has a list of customers to contact for additional analysis of the features that are selected.

Would you like to learn more about how Sage’s product managers have had success with VersionOne?  Register for our upcoming webinar.

To add items to the top or at least the first page, you have a few options:

First, you can create what I call a “ghost” story and place it either as the first item or somewhere on the first page. All it needs is a title (name is something like “keep on top” or “placeholder” and make sure you leave the estimate blank). Don’t forget you can customize and display up to 200 rows on the product backlog via the Customize option – under the wrench in the upper right-hand corner of the grid – so you can work with more items at one time.

When you want a new product backlog item/story, simply make a copy of that one and it will place the new item directly under the “ghost” one. From there you can drag and drop it to the appropriate location and add the details. It will even copy any tasks or tests you have on it.

For those who use templates to generate backlog items/stories, on the template page you can select the template(s) and rank them to the top any time you generate a new item from a template. The system will then place the item/story where that template currently is in the overall rank order. Note: you may want to re-rank items/stories periodically as new things come in and replace their location in the product backlog. See the steps below:

To move several items to the top, bottom or another page: (1) select the items you want to move, (2) select the “Move to Project” drop-down above the first column, and then (3) use the Rank option. Hint: Applying a filter is helpful in getting your list narrowed down to a subset and then selecting the items you want to move in bulk.

For those not using templates today, I encourage you to take a look; they’re useful for both product planning and for the team during Sprint/Iteration Planning.

You can create a template via the Product Planning page. Template the page by selecting “Add Template” in the upper right-hand corner:

Any data you want to copy or carry forward each time you generate a new backlog item/story should be filled in (i.e., a formatted description, the product owner, initial status, etc.).

Once you have created the template, you can then generate new items from the template in two places:

1.  On the left asset tray via the “Add New” drop-down:

2.  Or from the template page, select “Generate” on the action menu to the right of the template:

You can even take it a step further and add tasks and tests to the template. Those will also be copied when you generate a new item, and they can be copied to existing backlog items/stories via the “Plan Backlog Item” option on the Sprint/Iteration Detail Planning page:

From the “Backlog Item Planner” window, select the drop-down and choose “Copy Tasks and Tests.”

Scroll down to the bottom to see the template available, select the task you want to copy and choose “Copy to Backlog Item.”

I hope you have found these backlog grooming tips and tricks useful. Looking for more next year!!!

Here are some tips on using the VersionOne Project Navigator.

When you initially select the Project Navigator, you will not see the entire project tree; you will new see the most recently viewed projects:

You can choose from your recently viewed projects, search for a particular project, and you still have the option to see the entire project tree simply by selecting the Project Tree tab. In addition to seeing the entire Project Tree, you will also have options for filtering programs, schedules, closed projects, and single project views.