The Importance of Small Chunks of Work
Every Agile Software Development Team understands the importance of tackling work in small chunks the team can commit to truly finishing in a short period of time – meaning specifying, developing and validating. Small pieces of work are more easily estimated and relatively sized. Small work items can be more easily controlled to constrain Work In Progress (WIP) – a very important part of achieving a good velocity. And organizing the work this way supports a consistent measurable velocity for the team.
It is understood that it is easier to commit to work in 2 to 4 week iterations (aka Sprints) than in larger spans of time. People simply cannot project what can be done over longer periods of time. Things change, unanticipated events happen, requirements emerge – so it is more productive to complete a slice of the project and then make adjustments in priorities and specifications as new knowledge is gained and requirements emerge. Short incremental iterations support this process very effectively.
Short Sprint Validation Points
Short Sprint lengths also allow what can be considered validation points. The longer the time between such validation points, the greater the opportunity for misunderstandings and missed requirements. There are mitigations but these can be exhausting compared to simply doing the work in smaller increments.
The Challenge of Developing in Small Increments
This is not to say that developing things in such small iterative increments is easy. The greatest challenge seems to be with breaking down the work into small chunks. There are many techniques for this and this paper does not seek to articulate them. Rather we wish to point out that it is a dysfunction to exchange the hard work of decomposing work into smaller chunks, with returning to the uncertainty and false precision of longer Sprint lengths. History (and experience) has shown that lengthening the Sprint is scarcely ever the correct thing to do.
The Misconceptions of Longer Sprints
There are many problems with long Sprints – Student Syndrome, further regression into “mini waterfall” or “scrum-fall”, problems with planning and estimating to name a few. Many teams fall into believing that their ability to complete all their committed items will be improved by lengthening the Sprint. In fact such teams should examine the manner in which they commit to what will be undertaken in the Sprint. If they are struggling to complete committed work in a short Sprint then what would make them think it will be easier to commit to work in a long Sprint?
Teams may also believe they can become more efficient with longer Sprints. The idea would be that less time is spent in “overhead” activities such as planning, demonstrations and retrospectives. What is missed is that such activities are most effective when conducted every several weeks. These activities take longer and become less effective with long Sprints so the savings is illusory.
Resist Lengthening Sprints
So resist lengthening the Sprint and instead consider ways to be more effective breaking work into small slices and more efficient at planning. Finally, use the Sprint Retrospective to foster a culture of Continuous Improvement.
Rod Bray
Partner – Scrum Masters Inc
info@scrummasters.com
www.scrummasters.com
(v) 519 636-1558
Creating high performance software delivery teams
Scrum Masters Inc provides expert Software Development Life Cycle process improvement.
The services we offer include:
For more information about our services you can fill out our online contact form and someone will follow up with you shortly. You can also call John 312-778-6516