Better scrum user stories: Split stories horizontally, not vertically

Teams often run into trouble in a sprint when they’re trying to work with poorly split stories. Stories that are too big, too small, confusing or that mix the problem with the solution

We should split stories into small, discreet chunks of functionality. A single story should generally be the smallest discreet piece of functionality that adds business value. What is sometimes forgotten is that a single story should also have a complete user experience flow – it should bring the user from a determined start point to a complete, useful end.

When splitting large user stories down into smaller ones, remember to ensure the story captures a complete user flow. When splitting, think splitting horizontally, not vertically.

A horizontally split story will show a single flow, or path, through a user journey. (For example, a payment process that covers the simplest functionality, a single payment type, inability to modify your order, etc. The options are very limited, but the user is able to reach a useful end – ie, they can pay for something.)

A vertically split story will show multiple paths through a flow, but will stop before the flow can reach a useful end. (For example, a payment process that covers, at once, all the different payment methods that you ultimately want to support, but not the surrounding user flow.)

The problem with splitting vertically instead of horizontally is that vertical ‘strips’ have the entire complexity of the full, complete solution, but you lose the ability to test the whole flow properly. It is also far more tempting to dive into a pie-in-the-sky architecture discussion because to build all the full options for this one strip requires an understanding of all the inputs and outputs of the flow – most of which probably don’t exist yet.

An incomplete flow not only adds no user or business value to your product, but it’s very difficult for teams to build effective solutions for incomplete flows. Think and split in terms of thin, horizontal flows, and increase complexity with additional horizontal ‘layers’ (additional stories).

Better scrum user stories: save the solution for the spec

In the world of Scrum the user stories are at the heart of everything that’s added to the software: it’s how you break down the product strategy and requirements into discreet, develop-able chunks. We build software for our users, so it makes sense that everything that’s added to or taken away from the software is expressed in terms of a user need.

The Scrum textbook recommends the following standard form for a user story:

– As a user, I want to do {thing} so that I {reason}.

The trick is to focus the story on what the user really wants, not how you plan to solve that need. You need to keep the solution out of the story.

A couple of examples:

“As a user, I want to see my favourite places in a list so that I can find the one I am looking for.”

What’s wrong with this story? It is not a story about a user need; it is a specification for a solution. Does a user really want to see their favourite places in a list? Or do they just want to see their favourites? Is a list the only way to solve this need?

How about: “As a user, I want to find the favourite place that I’m looking for, so I can see information about it.”

Another example:

“As a user, I want to see Public Transport lines on the map.”

Do they? Or do they want to know where Public Transport lines run? Is putting them on the map the only way to do that?

How about: “As a user, I want to understand where Public Transport stops are in my city, so I know where to go to get the next train.”

Why is it important to keep the solution out of the story?

The User story represents the problem that the user wants to solve, to which you and your team need to find a solution. The steps to finding a solution are understanding the problem, brainstorming/investigating possible solutions, possibly in conjunction with benchmarking of competitor products and user research, then selecting a solution and specifying how that solution will work. When the solution is already embedded in the story, you spring over the first two steps, which not only means that you’re not looking at the problem broadly enough, and you will potentially miss good, new or innovative ways to solve the problem, but you’ll have no data to justify that the solution you chose was better than any other.

Write stories that focus on needs, and save the solution for the specification.

A good scrum sprint demo

The Sprint Demo is one of the most important meetings on the sprint calendar. So why are so many sprint demos so poor?

Firstly, why is the Sprint Demo so important? I think for several reasons:

  • It makes the progress (or, where applicable, lack thereof) of the team transparent (to management, to other teams, to themselves…).
  • It gives the team an opportunity to show what they have achieved and a forum to celebrate their accomplishments.
  • Ticking things off a list is fun!

I’ve had to sit through many exceedingly poor sprint demos, most of which could have easily been far better. Here are a few points or tips that I think can help get the most out of a sprint demo.

  • There should be an agenda. If you are demoing with multiple scrum teams at once, it should be clear in what order the teams are demoing. Each team should also have an agenda of which stories from the sprint backlog will be demoed.
  • There should be a demo computer in the demo room with an agreed and consistent configuration which connected to a demo environment. What is not able to be demoed on the demo computer isn’t demoed – this means no demoing from the developer’s local computer or any other temporary test environments. (Note: the demo computer configuration should ideally match one of your key users.)
  • The Product Owner should accept a story as done in the demo, or return it to development (ie, to the product backlog).
  • The Product Owner should remember to provide a bit of background to each story as its being demoed – specifically, what the business value for the story is, what problem the story is solving, what benefit there will be, and so on.
  • All issues discussed in the demo should be recorded and transferred to either the product backlog or to the bug tracking system. Some teams might like to appoint someone to be the meeting scribe, or the QA people may enter new defects raised directly into the bug system.
  • Stories should have passed a certain agreed defintion of ‘done’ before they are eligible to be presented.
  • Never cancel the demo. If the team has no stories to show, then display no stories at the demo – but never cancel it. Canceling the demo sets a bad signal to the team that demos aren’t important.
  • There shouldn’t be any surprises in the demo, and teams should prepare adequately for the demo if they want it to be a good one.

The demo is the chance to shine and celebrate for you and your team… make it count!

Chasing rabbits

If you chase two rabbits, both will escape.

You can’t run in two directions at once, and you have no way of controlling where the rabbits are going to run next. You can maybe influence the rabbits by setting up boundaries; you can maybe predict the rabbits by knowing the terrain, but you can never fully forsee how or where the rabbits will end up fleeing.

Many products fail or run into troubles when they try to do too much at once, try to grow in too many different directions or try to keep too many options open. Too many markets, too many users, too many options. Hedging your strategy is sometimes clever, but the problem is too much hedging and too many plan B’s not only increases your complexity overhead but creates noise and distraction – whether you’re prioritising user stories or defining corporate strategy.

The most successful startups and products in recent years do one thing, but do it really well. Twitter is the best micro-blogging platform. Foursquare lets you share your location with your friends. Evernote lets you take and organise notes. What are you good at? Where should you focus?

When you try to move forward with the most risk-averse strategy, you’ll end up moving nowhere. The project with the least likelihood of failure is probably the most likely to fail.

Recurring impediments

Last week I wrote about impediments, and making sure you go through them every day at the daily scrum standup. As I was discussing blockers with my team over the past week I noticed (again) that most of these impediments are recurring… they seem to crop up nearly every sprint.

Scrum teaches us about the impediments log, which you keep during a sprint to track the burndown of impediments. Even more interesting, I think, is to track a history of your impediments over time. Which ones turn up often? Which ones seem to cause the most interruption/downtime? What common themes are there?

This information becomes perfect input for retrospectives or general continuous improvement, and you can easily see the issues that are the most problematic or recurrent, and tackle them first.

What’s getting in your way?

The daily scrum standup is about answering three very simple questions:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. Do you have any blockers?

All three questions are important, but you know what… this is another great case where the whole is greater than the sum of its parts. It’s the combination of all three that make the standup as effective as it can be. 

I often see the third question get dropped from standups. I think developers naturally want to downplay impediments… I think they want to feel that they can solve them, no big deal. But the thing about forcing developers to articulate the things that might get in their way is not only so the Scrum Master or Product Owner has the opportunity to comment or act on them… the act of talking about your blockers forces you to think about it actively, and quite often things will come up that the developers themselves weren’t really aware of. 

On top of that, undiscussed impediments are like little icebergs floating around in your sprint… icebergs with which you will most certainly collide on the afternoon before the sprint demo, when you have no time to respond in order to save the sprint. Keeping an up-to-date impediments log is the best way to avoid nasty surprises on sprint demo day.

What gets in your way?

Scrum is not a solution to your problems

Scrum won’t solve all your development problems. Even if you implement 100% of the Scrum textbook (and most companies don’t), it won’t fix a broken development environment overnight.

Scrum process just helps to bring your problems to the surface so you can see them and deal with them. It’s all about exposing problems and issues, so you can identify them and do something about them. Scrum process aims to ensure that problems can’t fester unnoticed – but are brought to the attention of the whole team very quickly.

  • Scrum roles force defined and logical team roles and work division. You know exactly what you expect from a Product Owner, and he knows what is expected of him. If someone on the team is not fulfilling their role, it’s easy to spot, allowing you to do something about it.
  • Scrum meetings ensure that the team meets and discusses the appropriate things at the appropriate time. If the specifications are incomplete, if the stories are unclear, if the product vision is not defined – you will know it in the Sprint Planning meeting when the team can’t accept any stories. 
  • Continuous integration ensure that your development environment runs smoothly and minimises downtime or team-blocking integration issues. If there are intrinsic problems in the architecture, if the code is too brittle or if there are skill deficiencies in the team, you will see it in the CI environment.
  • Sprint demos give the team a target for a sprint and an opportunity to regularly celebrate what has been achieved as a team. But… if there are problems in the development team, if there are skill deficiencies or if the team is being blocked or interrupted, you will see it quickly at the sprint demo with the amount and quality of the stories that were completed.
  • Regular releases allow you to respond to your customers and stakeholders faster, and fix bugs or problems quickly… but if the team is not quality-conscious from end-to-end, you will see it in the quality of the code that is released at the end of the sprint.
  • Sprint retrospectives give everyone a chance to look back and think about what went well and what can be done better. Issues and team blockers will be raised by the team, and problems that don’t get fixed will get special attention…

It’s all about making the problems visible. Scrum won’t solve the problems that you have – that’s your job. 

Why the Product Owner is not the Scrum Master

Despite what is often the case in software organisations, a Product Owner is not a Scrum Master. To me, the two roles are both absolutely critical to the success of a scrum team, but they are not only very different, but quite often contradictory.

The Scrum Master protects the team from interruptions and blockers and facilitates their working together both within the team and with other teams. The Product Owner sets the direction of the team and the vision of the product and defines and prioritises the backlog based on product needs and input from stakeholders. 

Mike Cohn describes it by drawing a comparison to a pirate ship: if you consider the ‘management’ tasks that need to be taken care of on board Blackbeard’s Queen Anne’s Revenge, there were two main types: Star tasks (risk-taking, planning and strategic), and Guardian tasks (protective, ‘crew’ support tasks). 

The team should see and know the difference…

You can read the full article here.