LinkedIn principal author Doug Winnie describes how to monitor the progress of your build phase using a burndown model. A burndown model maps two main things: How much work or effort has gone into the project, and how much of the user stories and work items are complete for the release. Using these pieces of data, you can take the estimate and actual values and map them to see how they change.
- As your team is building out the features and user stories for your product, along the way, there are some key pieces of data you should collect from the developers on a regular basis. I want to show you how to use that data in a burn down chart to monitor their progress. The burn down is a key way for you to monitor the amount of effort put into building the product, and the amount of work remaining in the sprint or release. The first thing you need to know is how much time has been put into building the user stories and work items of the product.
The second is how complete the feature is based on the work that has been done so far. So, for example, if I have a developer that has three user stories assigned, on a specific day, I would hear that they put in six hours of work. Their first story is about 50% complete, the second is 10%, and the third hasn't been started yet. Using this information, you can begin to build a burn down chart to visualize their progress. A burn down chart has two sets of lines.
The first maps the percentage of features completed. This is based on your team telling you how much of the feature they are working on is complete. The rate at which features are completed is called your team's velocity. The line that is paired with that is a model line that indicates how much of the feature should be done by that day. So if I have a 30-day sprint, using a linear slope, I would need to have a little over 3% of the user stories and work items completed each day.
The other set of lines map the amount of effort put into building the user stories and work items. That line is paired with the amount of effort that should be done by that day. In this example, let's say we get about 15 hours of work done per day. In a perfect scenario, the work left to complete will go down consistently from 100% to 0%, with the actuals matching the estimate. And in the scenario described earlier, the effort put in would go from 0 to 450.
The lines will cross in the middle at the 50% point. In reality, your team won't be able to burn down the work at a consistent linear slope. Initially, the graph will not show much progress, but that will change as more progress is made. The end result will be a curved graph. You will find that there are many models for burn down graphs, and you will iterate on your own model as you learn more about how your team works and their velocity.
Building a product is never a perfect scenario, which is why monitoring is such a key part of the process. As a product manager, you can use a burn down chart to monitor and make sure that the release you are planning has a high degree of success, and make sure that you don't burn out your build team.
- Types of products and industries
- Leading through influence
- Understanding your team
- Using an agile or waterfall development cycle
- Managing your product life cycle
- Researching your market, customers, and ideas
- Planning the product
- Building the product
- Releasing the product
- Refining the product
- Understanding when it's time to retire the product