Month: February 2015

What’s in a name – Sprint Goals in Scrum

February 22, 2015 by Scrum Ronin·Comments Off

A Sprint Goal provides a focused objective for the team to produce an increment of software. It consists of a short description of a business or technical outcome that the team plans to achieve during the sprint, for example “Implement basic user profile entry (CRUD: create, read, update and delete)”.

Each sprint should be given a unique goal stating why the increment is worthwhile; this acts to align the team whilst planning, during the sprint and at the review.

Benefits of a Sprint Goal

The advantage to having a sprint goal is that it helps with –

Prioritisation – A goal supports the ordering of product backlog items when selecting content for a sprint. The Product Owner should select the initial goal for the sprint and then select stories to support that goal. Note that during sprint planning the scrum team may agree to change the sprint goal to reflect the work finally selected. Within the sprint the goal also becomes vital for the team when they are deciding ordering for tasks.
Focus – As well as providing a basis for the sprint planning session the goal provides a reason and shared objective for the increment to guide the team and enable commitment. The target is then for the team to accomplish the sprint goal and not just to complete the list of selected stories.
Feedback – Having a goal makes it easier to identify relevant users to review the increment and to receive quicker focused feedback. Analysing the feedback against a single goal is also easier than multiple disparate comments raised against several different stories.
Communication – Speaking to stakeholders and other agents outside of the team is easier when discussing what a sprint is for and helping them to decide if they should be attending the sprint review.

Creating a Sprint Goal

The product owner and development team agree the goal collaboratively in part one of sprint planning and like all targets it must be SMART:

Specific – The goal needsto be clear and unambiguousrather than generic. For a specific goal the team must agree on what is important, why is it needed, whois required, where it’s going to happen and which elementsare required, thiscan be summarised as the five ‘W’ questions:
- What needs to be accomplished?
- Why is it required?
- Who is involved?
- Where it is to be done?
- Which product backlog items are needed?
Measurable – The goal needs progress to be quantifiable, whether this is by seeing progress by the number of stories completed or by associated acceptance tests.
Attainable – It must be realistic for the team to be able to accomplish the goal within the sprint considering all other factors. A stretch goal by a high-performing team is fine if they decide to write it but, as always, it is the team that decides to accept the goal or not.
Relevant – The goal must address a challenge upon the project and move the team closer to the release or overall vision. Early sprints often focus on the reduction of risks and uncertainty (learning), later sprints generally focus on delivering customer features (delivery).
Time-bound – The goal must be achievable within this sprint.

Visualisation

The goal should be displayed prominently on the task board during the sprint so that the team can reflect on it at each daily scrum.

During the daily scrum the team answer three questions that reinforce the goal and work to re-align the team each day:

What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Roman Pichler shows an image including the sprint goal displayed on the task board in his excellent post on effective sprint goals:

Failing to Meet the Sprint Goal

If the goal is rendered obsolete then the product owner should cancel the sprint, this is understandably rare. Sprint goals can be missed by teams due to many reasons – insufficient understanding, over-committing, discovery of technical debt, resource reduction etc. Missing a sprint goal is an essential item to be raised during the sprint retrospective to find the underlying reason.

Accomplishing the Sprint Goal

Good work, the sprint goal has been demonstrated in the review and accepted. Another successful sprint chalked up, onto the retrospective and then straight into planning the next sprint.

Meeting the Spring Goal Early

Reality annoyingly does not always reflect estimates so sometimes a team will accomplish the sprint goal early, does this mean an early trip to the pub? Unfortunately not, the Scrum Guide states that the development team must collaborate with the Product Owner upon the scope of the Sprint backlog, this enables additional product backlog items to be pulled into the sprint.

Conclusion

The Sprint Goal is a great device utilised by Scrum Teams to add cohesiveness to each cycle of development. High-performance Scrum teams probably no longer need this uniting target and good luck to them, this blog is called Pragmatic Scrum for a reason so for now I will still be using a Sprint Goal.

Sprint Length: Pop Quiz, Hotshot

February 12, 2015 by Scrum Ronin·Comments Off

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

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:

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?

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 Length

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 Sprints

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

Definition of Done is easy right?

February 7, 2015 by Scrum Ronin·2 Comments

Rubber Stamp The 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 Problems

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):

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

General 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 Done

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.

You want to create another Scrum blog – seriously?

February 7, 2015 by Scrum Ronin·Comments Off

Welcome 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.