In my previous post: https://fithorizon.wordpress.com/2013/06/19/achieving-agility-in-a-waterfall-world/ I laid out the different phases of an agile project. As a reminder:
Hence during the envisioning phase we should focus on the Product Backlog, but at a high level. We should try to capture all the Stories/Product Backlog Item/Business Needs that will create your backlog. If you’ve been handed a 600 pages requirement document and you’ve told “We will use Agile, but we had to get all the requirements detailed upfront” then you may want to have a discussion about how agile the project is.
“How detailed should my Product Backlog Items (PBIs) be? (during the envisioning phase)”
At the envisioning phase you should have enough details to help you Understand and Estimate (at a high level) the work you need to do to reach the done state. After that estimation your backlog should look something like this:
This screenshot from a TFS 2012 demo project show some very important concepts. Every PBI has an effort, is assigned to a release (not a sprint) and the backlog is ordered by business value. This will allow you to Estimate cost and then if we are over what your stakeholders or your customers are willing to invest in that project, you can start to deprioritize into another release. Being able to order your PBIs by business value is critical, because if you don’t know the answer to what value that feature brings to the product or the project then you need to request more information. It’s an indicator for you to let you know whether you know enough about the project to envision it.
“How should my product backlog evolve”
The product backlog is a live list. It will evolve during the product lifecycle. During the Iterative implementation phase you can always glance at it to know what you have already achieved and how close you are from being done:
In the screenshot above, we are looking at the (Kanban) Board view of the Product during Sprint 3 of my Release 1. We can see what’s Done, What’s Committed and what’s not yet started. Stakeholder will be approving new PBIs as they get added to the backlog, reprioritizing them and your implementation team will be committing to them.
Keep an eye on how many PBIs you are consuming compared to new ones that get added to your backlog, that will tell you if you will make your initial release date, and more importantly what will make it or not. Here are few examples on how to do that:
1/ Using a cumulative Flow Report
2/ monitoring your team velocity (How many story points you are delivering per sprint):
3/ Forecasting when you will be done using an average velocity against your current backlog state:
This screen shows me that based on some velocity value I should be done in Sprint 6.
Your Sprint backlogs will be detailed to the task level and each PBI will have acceptance criteria (exit criteria):
At the sprint level the backlog has task estimations as well, that are not necessarily a match to the PBI estimate. These estimate impact directly your team capacity (green bars on the right).