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.
In this blog post, Mike Caspar gives a detailed answer to the question: What if your first scrum sprint ends up with zero story points completed?
“If the team is uncertain about how to achieve the sprint goal or if experimentation or prototypes need to be done, then the sprint should be shorter. Uncertainty implies that the work eventually required for the sprint might be significantly different from what was anticipated at the start. If this is the case, it’s better to change direction after two weeks than four.”
In this blog post, George Dinwiddie explains how to use the first iteration in a Scrum project to deliver some working software and not just building a backlog and setting up infrastructure for the next iterations that will deliver increments of functionality.
Martín Alaimo proposes to measure Scrum sprint progress with a continually updated ETC (estimate-to-complete) for each user story.
This blog post contains an interesting grid that help you analyze every aspect of your scrum project if you want to declare a sprint “done”.