Differences

This shows you the differences between two versions of the page.

Link to this comparison view

how_should_we_initially_track_release_progress [2016/07/03 13:38] (current)
Line 1: Line 1:
 +====== How Should We Initially Track Release Progress? ======
  
 +====== Premise ======
 +
 +In general the best approach to tracking Release progress when you get started is through a manual big visible chart showing stories moving from a backlog through "To Do", "In Progress",​ and "​Done"​ steps, and a chart showing the Release Burn-up, also manual. The reason we do this is so that teams can learn and understand how a Release is supposed to work without having to also learn the nuances (and potential changes in behavior) required by a tool.
 +
 +In some cases this approach may not work. For example, you might your Scrum Team might have remote members in which case a physical board in a room will not work very well for those people. Or you might want to have others see the progress of this team who, again, don't have access to the physical space. At the same time, you don't feel you are ready to select a tool as part of the work. For these situations it is often easier to start with a simple Excel spreadsheet to start the process. Below please find such as spreadsheet.
 +
 +====== Assumptions ======
 +
 +There are a number of templates out there but I found that there were problems with a number of them, especially as a "​starter"​ spreadsheet. Reason I have this one is:
 +  * It focuses on what we need for release reporting, while generating information for external folks
 +  * It applies the idea of “acceptable range” of values which helps teams understand normal variation as opposed to “problems”.
 +  * It does a couple of things well - burn-up progress, accuracy of commit, and reporting where we are putting our effort (investment categories). In particular it does not try to also be a Sprint Backlog (there is another sheet for that), just a Release Backlog.
 +  * There are no macros so its straight forward to enter information,​ and as the team needs to make adjustments,​ means that we can add capabilities over time. Teams are expected to evolve and, in the early days, evolve quickly. This means that the tools they use will need to evolve quickly as well.
 +  * Not much information is needed to get started.
 +  * Idea of tracking where interuptions come from for a team is useful when getting started (note - if you do not have this problem, don't bother entering information in the related tab)
 +
 +====== Sample Output ======
 +
 +===== Burn-up Chart =====
 +
 +{{:​sample_release_burn-up.png?​400 |}}
 +
 +===== Accuracy of Commit =====
 +
 +{{:​sample_accuracy_of_commit.png?​400 |}}
 +
 +===== Investment Allocation =====
 +
 +{{:​sample_investment_allocation.png?​400 |}}
 +
 +====== Template ======
 +
 +Basic instructions are included in the spreadsheet on the "​Instructions"​ tab. 
 +{{:​simple_product_backlog_and_burn-up.xlsx|}}
 +
 +
 +{{tag>​Consultant Tools ReleaseBurnup FirstSprint FAQ}}
 +
 +
 +~~LINKBACK~~
 +~~DISCUSSION~~
  • /home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_should_we_initially_track_release_progress.txt
  • Last modified: 2016/07/03 13:38
  • (external edit)