But I told the class I would publish it here for easy reference, so here it is.
It's a simple approach that works for both
- “Exploding the scope” of stories to find out what a customer could also ask for, but hasn’t thought of yet; and
- Breaking an epic or big story down into smaller stories.
Let’s use the following story as a demonstration:
As an iPhone user I want to sms my friends so that I can share gossip with them.
In order to explode the scope, we first make it more abstract (more negotiable if you use INVEST).
- Remove the statement that comes after “I want to” and replace it with the one after “so I can”.
- The story would now read “As an iPhone user I want to share gossip with them so {???}
- Now ask “why do you want to share gossip”?
- Repeat the process to make the story even more abstract if you want to; eventually, you will get too big, abstract but hopefully core user needs.
Now make the story more concrete again by asking
- How could you share gossip with your friends?
- How else?
You might then get a list of things like SMS; Call them; Semaphore; streaming video; MMS, Email, Poster. Which means your potential scope is now much broader.
Why would you want to explode your scope though?
- Firstly it provides options for the customer beyond the first solution they might have thought of. You can then de-scope the less useful options and deliver something better than originally expected; or
- You might find the scope is exploding all on its own, so you want to predict it earlier next time. By making the stories more abstract and then concrete again in the Initiate phase you might get a better grasp of what the customer will ask for later on and therefore be better placed to anticipate the real scope of the project.
As I said though, you can also use the approach to split stories that are too big to deal with, or that you want to shrink to the minimum complexity possible.
To do this:
- Remove the statement that comes after “so I can” and replace it with the one after “I want to”
- The story would now read “As an iPhone user I want to {???} so I can SMS my friends
- Now ask “What has to happen for you to be able to SMS?” or “What are some of the things you need to do in order to send an SMS?
- Repeat the process to make the story even more concrete (ie smaller) if you want to. Eventually, you will get to small stories that you can build easily, although they may not be valuable on their own.
- Now you can prioritise the smaller stories using an approach like MOSCOW so that you can find the most basic functionality that would meet the original request. That way you still meet the user need but effectively decrease your “bells and whistles” scope.
Give it a go and see how it works for you on your next Agile project.
Posted by James King