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.

Velocity is killing agility is the observation discussed by Jim Highsmith in this blog post. He explains that this metric is increasingly used for the wrong reasons: measuring productivity and focusing on volume delivery instead than on quality. He concludes saying that the importance given to velocity should be balanced with other metrics like feature value, feature delivery cycle time or quality.

The Scrum Expectation Line is defined by Zsolt Fabók as the line that follows the expectations of the Product Owner during each sprint. In this blog post, he discusses the difference between the team capacity to deliver and what the Product Owner wants in each Sprint and explains how his team deals with it.

In this blog post, Kristen Bornemann shares her thought about getting quick results from iteration in the context of the independent game developers. There is a fine line between making quick iteration a focus and getting bogged down in process.