Quick question, what sprint length do you use and why?Tape Measure

My guess is that you answered two weeks, I’m right aren’t I – well at least around 60% of the time.

Rally Software’s 2014 survey, based on 89,115 responses, shows the following results for the percentage of Scrum teams that use each sprint length:

sl2

The Scrum Guide being the fount of all knowledge gives the following rule – a sprint is a “a time-box of one month or less”. I don’t want to appear hardline but if your sprints are longer than a month you should really consider if you are doing scrum at all.

Fixed Sprint Length?sl3

When a sprint is in progress it’s duration cannot be changed, unless it is cancelled of course. The scrum master, in collaboration with the development team and product owner can elect, prior to a sprint beginning, to alter the duration.

The process is usually that duration is discussed in the sprint review in response to an issue and investigated within the sprint retrospective. When a collective agreement is reached the scrum master can decide whether change the sprint length, or not. The scrum master should strive to reach a consensus with at least the development team, as an adversarial relationship is not going to operate well at that level.

There is advice stating that if teams struggle to achieve all of the work within the sprint then the duration should be halved in order to force the issue and encourage change. This may be worth trying but really only in agreement with the team as it will be difficult.

Do not change the sprint length frequently as velocity becomes meaningless, meetings become difficult to organize and the team will be disrupted. Having said that do not be frightened to alter the sprint length if the project or team requires it.

One exception to this is the popular practice of running the first three sprints at one week for a new team to force the process under pressure to bed in. The first three sprints are usually all over the place in terms of velocity for a forming team so the risk is low. After the three learning sprints the team will generally revert to two weeks for the rest of the project.

Release sprints or hardening sprints are controversial but used by some teams still transitioning to Scrum. They are usually kept to the length of a normal sprint so as to avoid breaking the team rythm. Using a longer sprint reduces the need for these ‘false’ sprints.

Selecting a Sprint Lengthsl4

There is a lot of advice out there for selecting the duration for sprints based on risk, return on investment, feedback cycles, market dynamics but really my advice is just to pick two weeks and see how it goes.

The Goldilocks principle specifies that things should fall within defined margins, away from extremes. For most projects four weeks is too long and one week is too short so two weeks is probably just right.

Good overall advice for sprint length is “as short as you can, but no shorter”. If you cannot achieve a completed story with end-user value in a sprint to the product owner’s satisfaction then consider increasing sprint lengths, but only after trying everything else.

Converting teams from traditional methodologies to Agile is a journey, if as a group they feel that they need to start with a four-week cadence due to cultural, environmental or projects issues then accept it – for now.

You will see advice saying to avoid three week sprints, don’t listen – quoting natural cycles and the difficulty of synchronizing three weekly events is all rubbish. Three weeks is the second most popular choice for sprints, in my mind it’s not as good as two weeks (or even one) but at least it is better than four.

Shorter sprints, one week or less are great if you need to innovate faster than the competition and pivot quickly whilst seeking value. Lean start-up, fail-fast, excitement and energy are all heightened in shortened sprints, unfortunately so is the risk of burnout, incomplete work, lower quality and a short-term viewpoint. Day sprints would be great as well but only for the appropriate development.

With multiple teams working on a common product backlog it is important to synchronise sprint lengths. By this I mean that they need to align, not that they need to be the same. For example a HMI team may be running two-week sprints whilst the hardware team is on four-week sprints, they will still align once a month. In this case I would advise against three-week sprints, as they are a pig to align…

As always we have a complication, some teams use sprint zero as a preliminary increment in order to form the team, set up the development environment and perform enough architecture and design so that the project can begin. Sprint zero is limited to a maximum of three times the normal sprint length; with an average two-week cadence this gives a maximum length of six weeks. The Scaled Agile Framework defines an “Architecture Runway” for effectively the same purpose.

Long Sprintssl5

Teams with durations over two weeks often give some of the following justifications:

  • It is too difficult to break stories up for shorter sprints and still produce features with customer value. Longer sprints produce a viable product (false argument: improve story refinement)
  • It may be easier to have less frequent sprint planning meetings for larger teams (false argument: do better refinement to reduce and focus Sprint Planning)
  • It could be considered that shorter sprints do not suit long projects and month sprints may be better (false argument: reducing feedback cycles is always better)
  • There is less innovation in shorter sprints as teams will pick a risk adverse method in order to solve an issue, this may not be the most innovative or optimal solution (some validity but can generally be resolved by using spikes to prepare riskier stories)
  • Stake holder exhaustion, attending more frequent sprint reviews may not be viable or desirable for customers (some validity: the team would benefit from shorter cycles although the duplication of reviews for less frequently visiting customers is a waste. This is a balance in which a reduced frequency of customer involvement is not ideal but is reality for many projects)
  • Manual regression testing is not possible in short iterations (some validity: transforming legacy projects is difficult when testing is still manual, until this situation is remedied it may be better to run longer sprints)
  • The product owner may not be available to perform the role frequently enough for short sprints (false argument: the team either needs a new product owner or the PO needs to reflect on their responsibilities…)

I would ask these teams to consider experimenting by switching to two-week sprints for the following reasons:

  • It is easier to maintain a bow-wave of six weeks of sprint-ready stories (three times the sprint length) than twelve weeks worth
  • The team will be more agile and able to adapt to market and project conditions as there are less prepared stories
  • It is generally possible for the team to keep in mind all of the stories within the sprint and co-ordinate better
  • Scrum events (excepting the Daily Scrum) are halved in duration for two week sprints over four week sprints, this increases team focus and energy within meetings
  • Engineers still remember what they did at the start of the sprint, retrospectives can get slow when trying to remember four weeks back
  • Transparency is improved by shorter sprints allowing stakeholders to review and feedback on completed work more often
  • Feedback cycles are shorter for stakeholder feedback and also for sprint retrospectives. These frequent checkpoints make project progress easier to assess and future work simpler to plan
  • Longer durations allow teams to regress to waterfall within each sprint (ScrumFall)
  • Fail fast, if you are going to fail an entire sprint it is better if it is shorter at least
  • Shorter sprints increase motivation, four weeks sprint start casual, have lulls in the second and third weeks prior to rushed work in the fourth week to finish. This is similar to student cramming behaviour…
  • Shorter sprints tend to get disrupted less by stakeholder interrupts who can often await the end of a fortnight but will rarely wait for a whole month
  • Shorter durations encourage teams to work together in order to achieve the forecast work within the sprint, this also encourages teams members to work outside of their comfort areas
  • There is a good reason around sixty percent of teams choose two weeks, this is backed up by being the popular choice of many Agile trainers and coaches

Conclusion

Scrum provides great opportunities to inspect and adapt so collaborate to select an initial sprint length and following a bedding-in period of at least two sprints discuss and decide how to move forward.

Do favour shorter sprint durations over longer ones due to the improved feedback cycle but in summary, do what is right for your product and allow the team to decide.

Thanks for reading this far and apologies for the long posts, all aspects of Scrum are deceptively simple in theory but have so much depth in practice. The next post will be on the Sprint Goal, should be nice and short – or not. Please sign up if you would like to receive an e-mail whenever new posts are added.

sl6

Rubber StampThe Definition of Done (DoD) is a list of criteria that must be completed for a product backlog item (PBI) before it can be considered complete within a sprint.

The initial DoD is created by the development team at the start of a project, often in sprint zero. When multiple scrum teams are working on the same product backlog they must collaborate to agree a mutual DoD. It is critical that the DoD remains clearly owned by the development team; it cannot be changed by anyone else.

The DoD should be reviewed and expanded by the development team throughout the project in order to raise the quality bar. It should be possible to include wider activities into the DoD over time as organizational support improves and the ability of the team increases.

Note that the DoD cannot be changed during a sprint for any reason, additionally all work must be assessed against it. In the sprint review any work rejected or causing rework should be identified and subsequently analysed within the retrospective to ensure the relevance and completeness of the DoD.

The purpose of the DoD is to:

  • Provide a common understanding of completed work to both the team and the stakeholders thus reducing the risk of misunderstanding and conflict
  • Drive up the quality of work produced and ensure that quality level is visible
  • Provide an auditable checklist within the team and for QA
  • Ensure that technical debt does not build up on the project
  • Verify that integration and stabilisation activities are performed iteratively
  • Guide pre-coding activities (such as backlog refinement) to ensure all criteria can be met
  • Allow the team to focus on development whilst eliminating wasteful activities

Note that teams often need multiple DoD for stories, sprints, releases etc.

The Scrum Guide (2013) includes the definitive description for the definition of done.

Common ProblemsCoach Icon

It is common to see some of the following issues when coaching scrum teams:

  • Teams typically create an unrealistic DoD which prevents initial sprints from being successful and slows down the improvement cycle
  • Spending too much time producing the DoD and then striving to achieve it can be counter-productive. The focus should be to complete the minimum amount of work in order to complete a PBI
  • The DoD is generic whereas individual stories often require additional done criteria. Although it is usual to have acceptance criteria defined for each PBI, the DoD can mask this work
  • The DoD as a shared understanding must be explicit and displayed prominently on the wall (or task board). The DoD is less effective unless the contract is visible and prominent
  • ‘Done-Done’ – Some teams use multiple levels of done such as done with development followed by done with testing giving a ‘done-done’ state. I am unsure where this stops when additional steps are added – Done-Done-Done-Done-Done? I am really not keen on this approach, the definition of done should take the PBI to a potentially deployable state, i.e. ‘done is done’

It is a good idea to check that the team can point to it’s DoD and that the team uses it to justify if a PBI is to be included in the velocity at the end of a sprint.

Agile teams generally exist in one of five states with respect to the DoD (unfortunately not often in the last state):

  1. No DoD exists for the team
  2. A DoD has been created but is not generally used
  3. The team often fails to meet it’s DoD
  4. Although a DoD exists and is met for each PBI, there still remains work to be completed for each release
  5. A DoD exists, is met and includes all required work to deliver a PBI “from concept to cash” (Poppendieck).

Definition of Done scrollGeneral Content

The Definition of Done will vary from team to team and also by product, project, technology or domain. The criteria are often created by the team within an initial brainstorming session followed by a meeting to order, prioritise and vote on the content.

The following elements are often included in the DoD for a PBI (often a user story):

  • Design
    • Design has passed review
  • Code
    • Code is version controlled
    • Code builds without warnings or errors
    • Code has been refactored
    • Code meets standards
    • Code has passed review
    • Code has passed static analysis
    • Acceptance criteria met
    • Zero new defects
  • Testing
    • Regression tests pass
    • Unit test code coverage = x%
    • Automated functional tests for the the PBI pass
    • Integration testing passed
    • System level performance testing passes
    • Platform and localisation testing passes
  • Documentation
    • Technical documentation updated
    • Help file generated
    • User documentation updated

History of the Definition of DoneArcheologist

  • In 2002 Bill Wake wrote an article on coaching skills and exercises that included the term ‘done’ along with questions corresponding to it
  • In 2003 a slide title in Scrum training materials was ‘The story of Done’
  • In 2005 Scrum training materials got attendees to create a ‘definition of done’
  • By 2007 the Definition of Done was in widespread use as a standard Scrum practice

So that’s it for this week, I hope you found something interesting within the post so that it included some value for you. Please post a comment as I would love to hear what you thought. The next item on my backlog is Sprint durations so see you next week.

done stamp

cooltext1905135918Welcome to PragmaticScrum.info and let me start by clarifying that this is not another flavour of Agile but simply a blog for me to post my reflections on coaching Scrum.

My role as an enterprise Agile consultant enables me to travel around the UK helping engineers transform development practices by using Agile. I enjoy working at all levels of the company from the management board down to the teams that actually produce the products.

My goals for this blog are to encourage me to write regularly, to consolidate my posts in a single place and to be able to discuss knowledge areas that interest me.

I am aiming this blog at the journeyman skill level, those using Scrum who would like to learn more. There are already some great sites out there for starting scrum but I would like to hear more from real teams working to deliver complex projects.

Blog site up and running and introductory post complete – that’s two stories in my Done column already, a good start to sprint one of project Blog.

My next story is to create a post around the Definition of Done, thanks for reading.