In his article “Creating an ATDD Ready Sprint Backlog in Scrum“, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.
When you explain the iterative/incremental nature of Agile, most people coming from a waterfall lifecycle say “What? No up-front planning at all?” Some Agile coaches would glibly say yes, but the truth is more complex. Sprint Zero is an Agile term for a time-boxed amount of up-front planning. During Sprint Zero, you identify value stories, get a decent backlog of user stories and you do some architectural proof-of-concepts. The trick is to balance between insufficient planning and analysis paralysis.
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.
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.