You have just completed your development sprint, done the demo and the review, what next?
The easy answer is jumping into the next sprint. That is of course until the end of the year when reviews are up and you are asked to specify what you have been doing the whole year.
Showing working products is great, in fact, the agile manifesto clearly states:
Working software over comprehensive documentation
Note that they didn’t say No documentation!.
Even if they did, what seems very clear in your mind right now about how the days were used may not be so clear months from now.
Thus my recommendation is that you write a brief report for yourself. It does not need to be official. You can even just call it skipper’s log.
Below are some suggestions on what to include in the report.
Not everything that happens in a sprint will be seen in a demo. Perhaps Rico, your new developer, mastered SQL or your team was acknowledged during all hands and other search achievements.
If you do this consistently enough, you will have your team’s story, one that perhaps you can celebrate at your end of the year party, use to review salaries or make decisions on how and what to invest in the team.
Of course, the start and end dates of the sprint are obvious, how could they not be? Still, the past has a way of blending into what seems like one long day. In this cases, it helps to know that the Sprint commenced on 5th June and ended 15th June and that within this period there happened to be one public holiday or a team mate’s birthday.
This information may give you insights in future planning sessions, specifically how blocked of days for development play out in practice.
Thankfully, most project management tools aimed at software teams will automatically compute this for you. If yours doesn’t. It may be worth it to do the computation yourself.
Velocity = Total story points done in this sprint Average Velocity = Total story points complete/Total sprints done
You can then chose to plot this information in a burndown chart.
You may want to consider printing out the burndown chart and hanging it on your team wall if you have one.
Your retrospective will likely come up with good practices for the team to implement in the future. While this information is already captured in the retrospective document, I consider this information so important that a little bit of redundancy is allowed. In short, have it in your skipper’s log as well.
This will allow you to quickly reflect on what you thought at the time was important to improve on and thus see how things have evolved since then.
This would be a subjective account of how the sprint was. With all the talk about objectivity in our industry, telling you to record your subjective experience sounds rather counter productive.
Still, I have found that AHA moments can come from reflecting on your state of mind in action.
What do you, as an individual do at the end of the sprint? Talk to me in the comment section below or on my twitter @jchex