I was asked the other day why do I prefer shorter sprint duration, say 2 weeks instead of one month. I’d like to have shorter sprints for a number of reasons:
- Assuming we are motivated to demonstrate something tangible at the end of every sprint, with shorter sprints we end up looking for ways to produce something tangible sooner. The resulting sense of urgency in itself is good, although this is not about making our engineers work harder, that’s not the point at all.
- Shorter sprints encourage teams to master ways to break down large chunks of work into smaller independent user stories and as a result to better manage technical risks, helping increasing the odds of delivering more value at the end of each iteration.
- Shorter sprints motivate us to scope and size just enough level of detail and just enough user stories ahead (Just in Time) to help us deliver value and move at brisk pace. We gradually find ways to reduce and eliminate waste from our processes. For example, we learn that a user story that is thoroughly researched too far in advance often ends up collecting dust on our backlog as we may switch our priorities before we ever start working on it.
- With shorter iterations there is less time to procrastinate. Every day the team goes through daily stand up and it does not take long before we all know who makes good progress and who needs help.
- Shorter sprints help better manage risk across multiple scrum teams within a release. The longest a product team will go without knowing something is wrong is two weeks instead of one month or longer.
- With shorter sprints we become more nimble, more Agile as a vendor and competitor. In only two weeks we can pivot, change our priorities based on newly acquired knowledge, instead of sticking to the plan for one month or more.
No comments:
Post a Comment