Urban Turtle’s Product Management Feature will help Product Owners organize their business requirements into a single TFS project whether you want to manage a small, large or multiple team projects within the same TFS project.
This feature will help you to:
- Organize your user stories
- View business value progress statistics
- View effort progress statistics
- Plan your product using a roadmap
- Assign and visualize the business value of deliverables
Organize your stories
The Product Management offers you a way to organise and group related stories under several levels of containers. Most frameworks use this higher-level product structure as a mean to manage a portfolio. Each framework has its own definition of what a portfolio is, Urban Turtle gives you the flexibility to use the structure you prefer.
Some examples of common product structures are:
- When using the Scrum terminology, we typically group Stories within an Epic. Some teams also group their Epics within Themes when they need more classification.
- Microsoft, in it’s Agile Portfolio White Paper proposes to group Product Backlog Items under Features which are then grouped within Initiatives. Following their definition, the portfolio is composed of both Features and Initiatives.
- The Scaled Agile Framework groups Stories under Features which are then grouped under Epics. Epics represents SAFe’s Portfolio level.
If you run a smaller project or if you feel that a three-level hierarchy is too much, you can also configure your Product Management to use a two-level hierarchy. For example you could configure Epics containing Stories or if you are using Microsoft Scrum 2013 Process Template you could use Features containing Product Backlog Items and Bugs.
For the purposes of our documentation we will use the Microsoft Agile Portfolio Management terminology: Initiatives, Features and Product Backlog Items.
To help you organize your projects, keep in mind that a Feature should represent an objective that you want to implement for your end-users. It will probably impact multiple parts of your software. In terms of delivery, Features should be independent from one another and you should be able to release a Feature when there is enough value in doing so, even if other Features are still being developed.
Using the Business Value to develop what is truly important for your clients
One of the Agile principle states that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” (http://agilemanifesto.org/principles.html). To determine what constitutes valuable software, Product Owners need to think about what brings value to their customers. Either they calculate the ROI (Return on Investment) for each story, or they compare the value of each story using the T-Shirt sizing technique. One thing's for sure, today there is no standard formula for measuring value.
You will find a lot of information regarding the Business Value and the progression of your product in the Product Management view.
At the Feature level, information about the progress of the business value and the effort can be viewed.
Remember, the goal here is not to deliver 100% of the stories in a feature. At some point you need to ask yourself if developing those stories will bring more value to your customers that it will cost you to develop it.
Looking at Features, you have the ability to see the advancement of a given Feature’s delivery in terms of both business value and efforts.
You can take a closer look at the advancement of a Feature’s work items in terms of effort or business value by holding the mouse pointer over their respective progress bars on the Feature. This will show a tooltip containing more details on the progress.
Business value stats
With this tooltip, you will see your business value progression. As your feature’s development progresses, you may see that you are delivering a great deal of value early in your project and that over time, the delivery of value slows down. Depending on your business objectives, this could be a reason not to work towards completing 100% of a specific feature, but instead focus on other higher-value feature.
A warning will be shown if there are unestimated Product Backlog Items. Unpointed stories can impact the measure of your progress and can give you a false sense of advancement.
Plan your development using the Roadmap
By clicking on the calendar icon on a Feature, you can set the Feature’s start and end dates. The start date represents when the development team is expected to start working on the feature. The end date represents the expected completion date of a Feature. For the sake of planning it is best to set an end date that matches the date at which you expect to release the feature to your end-users.
When dates are appropriately configured, you can open the roadmap view. This will present the scheduling of your Features according to their planned start and end dates. This scheduling does not directly impact the real scheduling of iterations or stories.
This roadmap should be used as starting point for a discussion between the Product Owner and the management team concerning development priorities and release strategies.