The Treasure Island Retrospective

This short video demonstrates how to run a retrospective we devised and ran recently for one of our Scrum teams. It uses the  5 stages of a retrospective described by Esther Derby and Diana Larsen in their book Agile Retrospectives; “Setting the Stage”, “Gathering Data”, “Generating Insight”, “Deciding What to Do” and “Close Out”.

It asks the team to go in search of their treasure on Treasure Island, using their strengths to overcome any obstacles they might find on the way.  We hope you enjoy and thanks for reading/watching. If you use this we’d love to hear your experiences or any other opinions and thoughts you’d like to share with us about this retrospective.

Do you need a Scrum Master?

huh

Recently Alistair Cockburn, one of the 17 original Agile Manifesto authors, posted a question he was asked by a person called Gaboo, about the role of the Scrum Master.

Part of any Agile process necessitates stopping and thinking about the quality of the product you are producing as well as the quality of the methodology that is being used (12th principle ~  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.) With this in mind, questions about whatever framework we may or may not use should not only be asked, but embraced and seriously thought about when brought up.

Gaboo wanted to know:

  1. Is there anything implicit which says that the Scrum Master must have background in software process improvement and psychology?
  2. If they don’t have a professional background, how can they judge team dynamics and software development issues?
  3. How can the progress of the team or the performance of the Scrum Master be measured?

I immediately saw why Alistair posted this question. These are all extremely valid questions as the role of the Scrum Master is a bit hard to understand in the business world. Managers are responsible for planning, delivering projects and organising the team. If a Scrum Master isn’t directly responsible for delivering the product and the team decides how they want to organize themselves, what is the Scrum Master responsible for and what kind of skills do they need?

I posted a response to Gaboo’s questions and I answered as best I could without using definitions and doctrine. I tried to focus on my experience with the Scrum Master role and how it fits into our team’s dynamic.

  •  Questions 1 & 2 were similar and I tried to tie them together with this response: 
    It doesn’t hurt to have experience in software if you are coaching software teams, but not in order to solve their problems. It may be useful to have similar experiences to that of the team so you can relate to them. The Scrum Master position is concerned with enhancing productivity through collaboration, not through software or a commanding influence.
  • Question 3, about measuring the progress of the team and Scrum Master, I answered with:
    I think the only way I can attempt to share any insight on this is to indirectly answer your question with the thought that Agile (Scrum) is a framework to encourage empirical thinking/reasoning in a team. If a team isn’t iteratively looking at what it’s producing and how it’s producing it, it isn’t progressing. Because of the iterative nature of Agile (and thus Scrum) this evaluation is always being made. Though there are many tools to measure progress and influence, the very act of iteratively analysing the team is a progress indicator unto itself.

To get the full context of my answers, and a few more tid-bits concerning the Scrum Master’s role with impediments, you can read my full response on Alistair’s blog post on Why do we need a Scrum Master?

These are my thoughts on the subject. I’d be interested to hear about anyone else’s experiences/reservations on the role of the Scrum Master.

The Rope Game

We’ve put together a short video segment on one of the many learning games we play with people to help demonstrate the power of Scrum and Agile.

The Rope Game from Boost New Media on Vimeo.

We’ve also included the instructions for the game below.

If you are interested in using games to help your Scrum teams, we discuss the topic on our latest episode of The Board, The Board – Episode 6

—————–

The rope game

Time:

3 to 7 minutes

Materials

  1. 6 to 10 people  –> to form the circle
  2. 1 person to stand out of the group
  3. 1 metre piece of rope, per person in the circle

How to play

PART 1

  1. Ask one person to volunteer to be a “Project Manager” and step out of the team.
  2. Have the team form a circle (facing in).
  3. Give each team member a rope and ask them to hold it in their right hand and pass the other end to a person standing across from them.
  4. Ask each person, in turn, to pass their ropes across in the same manner until everyone is holding two ropes.
  5. Ask the Project Manager to direct the team so that it is untangled and standing side by side in a circle.
We normally allow them a minute to a minute and a half until we stop the exercise

PART 2

  1. Get the team to form a circle again
  2. Ask them to repeat handing across the ropes to re-tangle themselves.
  3. This time, ask the Project Manager to simply observe and not say anything
  4. Ask the team to untangle itself (typically takes between 20 to 40 seconds)

Learning

This exercise demonstrates the power of a team’s ability to solve complex problems when they collaborate. It resonates with Scrum in that you encourage the team to be self organising to get the full benefit of their abilities.

If you try the game, please let us know how it went in the comments below!

Scrummaker: the customer validation process

On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.

A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.

As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.

Customer validation: the research process behind Scrummaker

Customer validation has been at the heart of this project. It’s actually seen us take a completely different direction to the one that, three short weeks ago, we thought we were moving in.

Originally, we’d considered building a tool to solve one of our own pain points: turning stories in Pivotal Tracker into physical objects for sprint planning and visible workspaces. At the moment, our Scrum Master or our Office Manager spend a not-insignificant amount of time each week pulling stories out of Pivotal Tracker as CSVs, dropping them into project templates in Pages, tidying them up, then printing and trimming. We’d identified this as a pain point and poor use of our time, and considered building a tool that would integrate with Pivotal Tracker and automate this as much as possible.

We used two frameworks to conduct and capture our customer research. One was Lean Launch Lab, a product that helps you store and visualise your customer research. The other was the Validation Canvas from Lean Startup Machine, a simple one-page format for displaying assumptions, hypotheses, and pivot points.

The validation canvas for our product research

Validation canvas for Scrummaker (from Lean Startup Machine)

We conducted research in a number of different ways. The most complex was using unbounce to set up a landing page for our theoretical new product. We used LinkedIn advertising to promote the page, and tracked conversions from people visiting the page to following a call to action to sign up or find out more. We ran a poll through the LinkedIn Scrum Practitioners group, and we also conducted a series of email and face to face interviews with Scrum practitioners in Wellington and around the world.

What our customer research rapidly showed was that our ‘printing out stories is a pain in the ass’ sentiment wasn’t widely shared. (Perhaps, being a design-led company, we worry a tad too much about everything looking good as well as working well.) Instead, what emerged was a cluster of concerns around retrospectives:

  • they aren’t always valued by teams and/or organisations
  • they are hard to run with distributed teams
  • it can be hard to generate actionable improvements
  • it can be even harder to track whether these actions are taken and what the outcomes are.

Some market research showed us that few tools already exist to tackle these problems. At this point, we felt confident that we had a good problem to solve. What could we build that would help Scrum teams run efficient and valuable retrospectives?

Our next step – and the next post in the series – was to run an experience mapping workshop to generate a product backlog …

Scrummaker, or, building a new Agile product in two days

On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool for teams running Agile retrospectives that we’ve named Scrummaker.

The purpose of the workshop was three-fold. We wanted to build a new product. We wanted to build a new product as a team. And we wanted to build a new product as a team using the Agile practices we’ve been working with now for about six years.

We’re now publishing a series of blog posts to record the two days of product development: what we made, and how we did in. The blog posts are only the beginning; we also had a crew of student filmmakers along for the two days, recording all the goings-on for a short documentary.

The first posts will cover the project lead-in: customer validation of our product ideas, the experience mapping workshop we ran to generate the user stories for the product backlog, the time-boxed technical discussion the team held to ensure we’d hit Thursday morning ready to work. There’s a post on the project kick-off, and then the meat of the series: what we learned from two days of compressed Scrum, and the product we came out of the end of the process with.

So grab a cup of whatever makes you happy and settle in for the read ….

  1. Customer validation for Scrummaker
  2. Experience mapping workshop
  3. Technical discussion
  4. Project kick-off

Business Analysts and Scrum projects: A short case study

In a recent post I discussed the question “Are user stories the same as use cases?”. This is a question that frequently arises in our Writing Great Agile User Stories workshop, and it’s often asked by business analysts. I’ve also been in Agile/Scrum training courses with BAs, who at a certain point in the day start worrying about where the BA role fits in a Scrum project.

The quick answer is: there is no Business Analyst role in Scrum – just like there isn’t a DBA role or a SysAdmin role or a designer role. You’re either the Scrum Master, the Product Owner, or part of the Scrum Team. There also isn’t a space carved out for a person to be responsible for requirements gathering and reporting.

The longer answer is that there’s still a lot of work in a Scrum project for a good BA to do. As Roman Pichler puts it:

what’s left to do for business analysts in Scrum? I have seen business analysts working as team members as well as taking on the product owner role successfully. In both cases, though, the individuals experienced a change in their daily work. Business analysts working as a team member often support their peers in product backlog grooming activities. As the business analysis activities are now carried out collaboratively, the business analysts often have time to take on other responsibilities, for instance, working with the testers or the technical writer. As a business analyst working on the team, you should hence expect to pick up new skills, broaden your expertise, and be open to work in new areas.

One small case-study

I recently worked on a short (6-sprint) Scrum project that had a nearly full-time BA allocated as a resource to the team. (Don’t you love that kind of phrasing? “allocated as a resource”. Savour it.)

We were creating a mobile interface for a cut-down set of the functionality available through our client’s current website. Our team was made up of a mix of our client’s staff and Boost staff: a Product Owner, the BA, two developers and a tester from our client; a Scrum Master, designer and me doing the wireframes from Boost.

Here’s what our BA did:

Working with the product owner

  • Research for writing user stories (usually by confirming how the current system works, and where there was and wasn’t flexibility to make changes)
  • Meeting with other parts of the business to explain what we were doing and what we needed, and to find out what they were doing and how that might affect what we were making.

Working with the team

  • Ferreting out system documentation
  • Getting screenshots of the system that I (working outside their network) couldn’t access, and reviewing wireframes with me
  • Helping write and QA’ing test cases
  • Getting wording signed off by other parts of the business (always harder than you think it’s going to be)
  • Getting approval from other parts of the business for use of a third-party plug-in.

Our BA attended all the planning meetings, retrospectives and stand-ups. Her work was managed just like the rest of the team’s: written as tasks and posted on the Scrum board. What she didn’t do was write requirements or use cases, or reports. There was huge value in having her on the team: she was our go-to person for all the tucked-away documentation and hard-to-find system descriptions.

Further reading

A four-part article based on a roundtable discussion amongst a group of Agile experts (including Alistair Cockburn, Roman Pichler and Ken Schwaber) on business analysis and Agile

Colart Miles has begun a promised series on the Clarus blog

Use cases vs user stories in Agile development

TL;DR – User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, (largely) removing the need to write use cases.

Are user stories the same as use cases?

When running our Writing Great Agile User Stories workshop, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story.

Looking around the web, there’s consensus that use cases and user stories are not interchangeable:

My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act. And then I say “Just bear me – it will all be clear in soon”. But I thought it was time to dig further down into this.

Use cases and user stories

Let’s start with some definitions.

A user story is a short description of something that your customer will do when they come to your website or use your application/software,  focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use. A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.

A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:

  • Use case title
  • Rationale/description/goal
  • Actor/user
  • Preconditions (the things that must have already happened in the system)
  • Standard path or Main success scenario (what will usually happen, described as a series of steps)
  • Alternate paths or Extensions(variations on the above/edge cases)
  • Post conditions (what the system will have done by the end of the steps).

At first blush, use cases look like a much better way of writing requirements than user stories. How will a team be able to implement something as wafty as As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos without some rigorous use cases to detail the requirements for the system? And that’s usually the point when someone in the workshop asks that question.

Writing use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop that user stories are just the start of a process of understanding what the team is making that, by the end of its course, covers off everything a use case would have told you, but in an organic manner.

Acceptance criteria

User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:

  1. A user cannot submit a form without completing all the mandatory fields
  2. Information from the form is stored in the registrations database
  3. Protection against spam is working
  4. Payment can be made via credit card
  5. An acknowledgment email is sent to the user after submitting the form.

Writing the acceptance criteria is the first step of fleshing out the details of your user story

Sprint planning meetings

In the sprint planning meeting, the product owner presents the user stories from the top of their product backlog (ie. their highest priority features) and the team commits to the stories they will complete in the sprint.

As the product owner presents the stories, the team will ask questions to further clarify the user story and the acceptance criteria. Assumptions will quickly be confirmed or corrected, and any ambiguity about the requirements starts to disappear.

This assumption and ambiguity erasure continues as the team estimates the stories (if five people on the team rates a story as a 2, and one person rates it as a 5, there’s probably some questions that need answering). And it’s repeated again as the team writes the individual tasks for each story.

Standups

We’ve been fortunate in our Scrum projects, in that our product owners generally commit to attend the team stand-up. This is another chance for the team to ask questions, and also to make the product owner aware of restrictions, issues and opportunities are appearing as the story progresses.

Wireframing

I do the wireframing for some of our projects, and usually I start by talking to the product owner about the story, and sometimes making some paper or whiteboard sketches. I turn these into wireframes and then there’s normally a couple of quick iterations with the product owner as we ask each other questions, get feedback from other people, and hopefully squeeze in some user testing.

More recently, I’ve started reviewing the draft wireframes with the designers and developers working on the story. This helps flag up any questions they have, or restrictions I might not have been aware of. After the wireframes are approved by the product owner, I’ll brief the designers and developers again if needed.

Design and development

Although most of the details have been thrashed out during the wireframing more can crop up at this stage, and there are often more questions for the product owner about exactly how they want the backend of the system to behave. Pair programming is useful here, because two sets of eyes on a piece of functionality mean yet more questions and clarifications.

No user story is submitted for acceptance by the product owner until the acceptance criteria are satisfied and the definition of done is met.

Overall

This might sound like a lengthy process. In reality, it’s just what a Scrum team does all day. Rather than one person labouring over the use cases, the team works together to surface and satisfy all the requirements. The product owner can refine the original acceptance criteria in response to new information throughout a user story’s progress.

And finally, in conclusion

There are exceptions, of course – and there are times when the upfront research needed for use cases is important (I’ve got a blog post brewing on this). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team does ask for them, spend some time in a retrospective digging into what they’re not getting from your current processes (for example – are the acceptance criteria unclear; is the product owner  unavailable; are you working with shitty documentation for another system). Then decide as a team how to fix the root problem.

Further reading

Advantages of user stories for requirements – Mike Cohn

Requirements 101: User stories vs use cases – Andrew Stellman

Tina Fey’s Four Rules of Improv, as applied to Scrum

Driving home for Christmas, I listened to the audiobook version of Tina Fey’s Bossypants.* Listening to her read the chapter Rules of Improvisation That Will Change Your Life and Reduce Belly Fat, it struck me that the four rules of improv that she describes translate well to the spirit of Scrum projects.

1. The first rule of improvisation is AGREE. Always agree and SAY YES.

This rule for me is about openness and the willingness to engage with new ideas and new practices. As Fey explains it:

When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt.

The blue screen of death moment is any meeting is when you hear someone say ‘We can’t do that’, or ‘We tried that before and it didn’t work’ or ‘The IT team won’t let us do that’. That moment sucks away at your enthusiasm for the project and if it happens enough, drains your will to work.

A recent Scrum project I worked on had a brand new team working to create a prototype for a mobile app in six two-week sprints. At the beginning of the project, the team’s most common reaction to the Product Owner’s stories was ‘We can’t do that, because…’. This resistance was a real downer for the Product Owner. By the last sprint, the team was saying ‘We can do that by ….’,  explaining what the potential issues were, and suggesting how to overcome them. The Product Owner told me this was one of the most satisfying aspects of the whole project for them.

2. The second rule of improvisation is not only to say yes, but YES, AND.

If your reply to “Freeze, I have a gun” is “Yes, you have a gun”, that doesn’t do much to advance the scene. YES, AND for Fey means not being afraid to contribute – in fact, seeing contributing as your responsibility.

When I heard this, I thought about things from the Scrum Master’s point of view. At the start of a project, when you’re the Scrum Master, you sometimes find yourself trying to coax quieter team members into joining discussions. You don’t want to have to do this for much more than a sprint or two. A team that needs the Scrum Master to help them talk about stories or solutions isn’t self-organising. The Scrum Master can however help create an environment where no-one feels afraid to contribute, and coach people to see contribution as part of their role on the team.

3. The next rule is MAKE STATEMENTS.

Fey writes:

This is a positive way of saying “Don’t ask questions all the time.” If we’re in a scene and I say, “Who are you? Where are we? What are we doing here? What’s in that box?” I’m putting pressure on you to come up with all the answers.

In other words: Whatever the problem, be part of the solution. Don’t just sit around raising questions and pointing out obstacles. We’ve all worked with that person. That person is a drag.

I took two things out of this. One was that MAKE STATEMENTS would be a handy poster to put up next to a Scrum board if your team has a tendency to turn a 15 minute stand-up into a 45 minute philosophical discussion.

The other thing was a reminder of how much I love the way Scrum lowers the threat level of decisions. When you’re responsible for a project, making decisions can be scary. Signing off the final design in a waterfall project, for example, means acknowledging that any changes you want to make further down the line will almost certainly be difficult and expensive. If making decisions is stressful, one natural reaction is to delay or obfuscate. However, when you’re a Product Owner on a Scrum project, you’re making decisions all the time. You get used to making the best decision for the moment, and understanding that if you need something to change in the future, you’ll just write another story. This lowers the threat level of decisions considerably, and helps your team a lot: making decisions is a lot like making statements.

4. THERE ARE NO MISTAKES, only opportunities.

If I start a scene as what I think is very clearly a cop riding a bicycle, but you think I am a hamster in a hamster wheel, guess what? Now I’m a hamster in a hamster wheel. I’m not going to stop everything to explain that it was really supposed to be a bike.

The lesson here for Fey is that some of the world’s greatest discoveries have been happy accidents (think Viagra). There’s a useful lesson here about being open to suggestions and discussions, rather than clinging to your original set of assumption and opinions. This is why user stories are written in terms of what and why, rather than how.

In conclusion

Firstly, Bossypants is a great read (or, if you like audio books, a great listen).

Secondly. Improv is the act of working together to build something new from a bunch of quickly generated ideas, pruning off things that don’t work and building on the things that do along the way. The more an improv team works together, the more they trust each other, and the better they know each others’ strengths and how to use them. A lot like Scrum projects, over all.

*I was recounting this to a friend over the weekend, who flummoxed me by asking who Tina Fey is. So just in case – ladies and gentlemen, Tina Fey.

The 2011 Scrum Guide – a quick review

Here at Boost we’ve been reviewing the updated Scrum Guide by Jeff Sutherland and Ken Schwaber, released in July (you can download the guide at Scrum.org)

Rather than covering techniques (like release planning, burndowns and sprint tasks) the guide focuses on what makes Scrum Scrum: the roles, events and artifacts, and the set of rules that bind these together.

In an introduction to the changes from the 2010 Scrum Guide, Schwaber and Sutherland compare the Scrum Guide to guides for games: rules (pass go, collect $200) are different from strategy (get to three houses as quickly as possible, because this is when the rent bumps up dramatically). They write:

The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on.

Strategies for playing Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those of us working on a revision to the Scrum Guide, this meant that all tips, optional practices, and techniques should be removed from this document. This was done along with refining some language to correct some long-standing misunderstandings about Scrum.

Given the Introduction to Scrum workshops we’re running at the moment, we were keen to look at the Guide in terms of how it can help us teach people about Scrum. Here are some of the passages that really grabbed us:

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

We often explain that a key part of the Scrum Master’s role is to clear impediments that are stopping the team from working as well as they could. Here, we like the notion that the Scrum Master isn’t just clearing blocks, they’re teaching people to proactively stop the blocks from happening.

… each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

We’re frequently asked whether all the events in Scrum (stand-ups, planning meetings, task estimation, demonstrations, retrospectives) are really necessary. We usually say that of course you should use the structure and methods that suit you best – but that if you’re not following the Scrum events, you’re not using Scrum.

We also try to explain how you can go through the motions of Scrum events without getting the benefits. Thinking of every event as an opportunity to inspect and adapt, and to create transparency, reminds you of why these events are held and the spirit in which people need to participate.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, a Product Backlog also exists.

The Scrum Guide’s section on the product backlog  really emphasises that the product backlog isn’t there just to get you to an initial release – it is a long term commitment. In fact, the Guide states that the product backlog will become ‘larger and more exhaustive’ after launch. Interestingly, the Guide also dwells on the role of team members in contributing to product backlog grooming, not just the product owner and stakeholders/subject experts.

Overall, the 2011 Scrum Guide is concise (a slim 16 pages), focused and a useful resource for newbies and experienced Scrum practitioners alike. Enjoy!

More reviews of the differences between the 2011 Scrum Guide and earlier versions:

Improving user stories with a Definition of Ready

In Scrum, the definition of done tells us when a feature is completed to a releasable standard. It sits above the individual acceptance criteria for each user story. For example, here’s the definition of done for development stories from one of our projects:

  • committed to source code repository
  • passes appropriate tests for story (including cross-browser testing)
  • tests written and run on integration server
  • accepted by product owner on UAT (unless story asks otherwise)
  • documented (well-commented)
  • cross- browser testing of interface elements
  • readme updated if applicable
  • change log updated

Adding the definition of ready to the definition of done

Recently, we’ve been looking at the definition of ready – the criteria a user story has to reach before it can be handed over to the team. You can think of the definition of ready and the definition of done as two key points in the sprint cycle – one defines when a story is ready to go in, and the other defines when a story is ready to come out.

Jeff Sutherland and Carsten Ruseng Jakobsen have described a definition of ready as a simple concept that depends on discipline and creates stability in a sprint. It’s designed to stop time being wasted when it’s discovered that user stories are missing important pieces of information that means they can’t be started or completed.

A definition of ready gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, as Sutherland and Jakobsen observe, a definition of ready can improve the flow and stability in a sprint.

A sample definition of ready

Here’s a definition of ready we’ve  developed for one of our projects:

  1. The business value is clearly articulated (in the format of ‘As a type of user I want some goal so that some reason‘)
  2. The story follows the INVEST model
  3. The story has a 2 – 3 word short summary
  4. The story is small enough to fit in one sprint
  5. The story has clear and concise acceptance criteria which describe all of the features of the story. Details are captured as a narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system.
  6. Once the acceptance criteria have been met the story is complete
  7. No external dependencies block the story being completed
  8. Story identifies external expertise and provides contact details.

Many of the points (for example, 2,4 and 5) reinforce the usual expectations of a good user story. Some are designed to trouble-shoot in advance: for example, 7 and 8 are there to help the team work as efficiently as possible, by ensuring they’re not being held up by business processes outside of the team, and have ready access to any expert help they need. And some are small tweaks that add efficiency in the longer term – for example, point 3 ensures we have a short headings for the user stories that make them easy to scan in Pivotal Tracker.

In conclusion

Of course, having a definition of ready doesn’t mean there won’t be occasions during sprint planning meetings when gaps are found in the preparation or understanding of a user story. It also doesn’t mean the team no longer has to talk the stories through with the product owner during these meetings, and throughout the sprint. But it does mean you’re creating the best possible conditions for optimal productivity in the sprint.

More reading: