Matthew Evans shares with us an Excel spreadsheet that allows to record and visualize informations about your Scrum sprint. One sheet allows to manage the sprint data with the estimated and actual work for each story. A project page consolidate the sprints data at a project level. Visit the “Agile scrum project management spreadsheet” page to get the spreadsheet.
What should be the lenght of a Scrum sprint? There is no unique answer to this question. In this blog post, Mitch Lacey provides some key factor to consider when you try to choose the right sprint length for your Scrum project. These should be considered looking at the expected duration of the project, the customers/stakeholders and the Scrum team. His conclusion is that the right sprint length balances a craving for customer feedback and input with the team ability to deliver and the customer’s ability to respond.
A lot of things can go wrong during a Scrum sprint. In his blog post, Ilan Goldstein makes a list of some common issues in Scrum sprints and how you should deal with them. He recommends to gather as much data about these speed humps as possible so that you can inspect and adapt your processes and start bridging the gap between theoretical planning and reality.
Companies that transition to Agile often adopt the analogy that sprints are just mini waterfall. This article provides five reasons why Scrum sprints are not mini-Waterfall. Each argument is illustrated by a diagram that provides a clear visual evidence of the difference between the Agile approach and a traditional process.
Thom Roach shares with us in this blog post the metrics that he includes in iteration summary reports. The three main statistics he uses are Iteration Statistics summary, Iteration Cumulative Flow and Team Velocity Chart.
Short cycles provide us with a wealth of benefits in terms of fast feedback, minimal design in process and increased flow. Plan driven sprints however stress the system, force good people to make bad decisions and is built on the faulty belief that capacity utilization is the main problem in high variability environments like product development.
Mike Cohn wrote an interesting post where he discusses he allows or even encourages to estimate with story points as large as 20, 40, and 100. He explains that they are useful when you need first and not necessarily precise estimate of the general size of a new project being considered.