Every team that transitions to agile faces this problem – some stories are too big to fit in a single sprint. Most of the teams that I have worked with have the wrong instinct – to solve half of the problem for all users.
The right approach is to first solve all of the problem for a subset of the users.
The Goal of the Story
User stories were created as lower-overhead use cases that served to better describe chunks of valuable software that could be rapidly developed, delivered, reviewed, used, and improved. Writing user stories that undermine that intent – rapid, valuable, incremental delivery – is a bad way to write user stories.
Imagine you are part of the team building GoToAssist, a product designed to do this. Your product manager and product owner put the following story into the top of your backlog – it is the most valuable capability you could add.
As a provider of IT support, I need to remotely resolve issues on multiple computers simultaneously, every day, so that those computers will run well.
The acceptance criteria include requiring that the solution working when accessing Apple computers, and PCs running various versions of windows and Linux. Other acceptance criteria include allowing the solution to work well through network connections having minimum characteristics, not requiring the remote users to take action, and other elements that characterize what would be considered acceptable solutions by the stakeholders.
Your team immediately raises a red flag that this user story is “too big” for a single sprint.
Since the goal of the sprint is to deliver valuable, shippable software, you have a problem with any user story that cannot be completed within a single sprint.
No problem, just decompose the user story into smaller user stories…
Inside-Out User Stories (Bad)
Note: Don’t confuse making smaller user stories with defining the tasks required to implement a user story. Task definition is important and valuable for helping the development team organize their activities. Making smaller user stories is not a good approach for organizing the team’s activities – use tasks instead. The size and structure of user stories should align with the user’s goals.
An inside out perspective or approach is one that starts with an awareness of what is involved in creating the software, and either never, or only later considers the perspective of what it is like use the software.
When approaching the problem inside-out, you will break the story down as follows:
- As a provider of IT support, I need to remotely gain access to multiple computers simultaneously…
- As a provider of IT support, I need to remotely authenticate as an administrator to each computer I access…
- As a provider of IT support, I need to remotely control each computer I access…
- As a provider of IT support, I need to remotely restore control of each computer…
This approach looks very appealing, because it is very clear what has to be done to support each new user story, and each new user story is appreciably smaller. Assume that each new user story is “small enough” for the team and does not need to be further reduced in size. It is very easy to see how the scope of development work has been reduced for each user story.
The problem shows up when you approach this schedule from a user’s perspective. Imagine that this product shipped with only stories 1 & 2, and not 3 & 4. How useful would the user find the product to be if she could remotely access a computer and authenticate, but not actually control the computer (to do her remote support work) or return control to the computer’s owner?
The reason you should not break the original user story up into these pieces is that the new stories do not independently represent delivery of valuable software. These proposed smaller user stories are atomic (each step is discrete), but each step has no independent value. The value is implicit in the sequence of steps, and is only realized when all four steps can be completed. The original story is already the smallest set of activities that allow the user to achieve his goal – a complete user story.
The problem with decomposing the original user story from the inside-out is that the new user stories don’t provide independent value to any of the users.
What about trying an approach that provides all of the value to some of the users?
Outside-In Story Decomposition (Good)
You are still faced with the challenge of making the story smaller, but now with the constraint of only delivering pieces that provide independent value. You need an approach that will work to split the story up per-user. “Provider of IT support” is an overly broad category of users – it is heterogeneous, within which different groups of users will use the product differently. I am a “provider of IT support” to my family, but I never have a need to access multiple computers simultaneously. I also don’t need to do this more than once a month on average. A corporate IT specialist responsible for 100 users would really benefit from simultaneous remote access to multiple machines – allowing her to multi-task, starting updates on a second machine while the first machine is working, etc.
There are at least two different personas that care about the “remote administration” user story, within the “provider of IT support” user category. One persona who needs to access only one machine at a time, and one persona who needs to access multiple machines simultaneously. This split allows you to decouple all of the work associated with managing simultaneous connections from the work associated with the sequence of steps (as applied through a single connection). This may reduce the size of the original user story enough to complete it in one sprint, but probably not, since it only “shaves off a little work.”
Another way to discover different sets of people who could benefit from delivering the user story differently is to look at the acceptance criteria.
Right off the bat, we’ve called out that the solution needs to work when the remotely accessed computers are running several different operating systems. You can make the user story smaller by constraining to one supported platform at a time. Whichever platform you pick first – say Linux – has some users who will value your solution. Start with them, then add another platform. Work with the product manager to determine how many customers in the market will require each platform or combination of platforms – that will guide the sequence in which you build support for each platform.
Another acceptance criteria required that the remote users not need to be involved – enabling “unattended” remote support – a key market differentiator. A key differentiator for the corporate IT specialist persona, who gets value from not having to coordinate support activities with multiple remote users. In fact, it is probably a must-have feature for those customers. As a family-support specialist, I don’t really have this need. My mom is going to call me, and I can fix her pc while we’re on the phone. I’m not trying to remotely administer her machine when a corporate policy has changed (on my schedule) – I’m doing it when a problem arises (on her schedule). This criteria can be deferred for a later iteration of the story
This approach works because, while it may be not be intuitive (from the inside) that this is a viable way to decompose the story, it makes send from an outside-in, user perspective. Think about the different sources of value / problems, and how different people value solutions to the same problems differently. The important characteristics of the problem will vary from one persona to another.
What About Development Efficiency?
As a developer, you may very correctly complain that this is a really inefficient development process. Some portion of the work done to enable controlling a single machine may need to be discarded and recreated in order to control multiple machines in parallel.
While these extra development costs are very visible, especially to developers, they are much smaller than the benefits that come from delivering the working software earlier. The cost of resolving bugs increases by orders of magnitude as you move through the product creation life cycle (from development to testing to deployment). The value of solutions also increases by orders of magnitude as they move through the process. Getting working product deployed earlier allows you to start realizing value (and therefore revenue) earlier.
That increase in revenue far outweighs the cost of a less-efficient development approach. Ignoring revenue side and focusing only on the cost side is being penny-wise but pound-foolish.
Dogma and Pragmatism
None of this should be taken as dogma. My experience has been that this approach has almost always worked, sometimes requiring more radical thinking than others. When it does not work (e.g. does not provide additional value, or does not sufficiently reduce the size of the stories), don’t do it. I’ll always remember Kent Beck saying to me – “If it costs more to test (in advance) than it costs to fix the bugs (after the fact), then don’t test.”
The same applies here, be pragmatic about it.
If you’ve been biting your tongue since the middle of the “Inside-Out” section, because you can always just wait until all four user stories are completed in separate sprints, before releasing the software, then my apologies. Of course you can do that. But you are undermining a precept of Scrum – that every sprint could be released, if you needed to release it.
That may not apply to you – I work with some teams that develop enterprise software, and for them, releasing every sprint makes no sense – their customers can’t absorb the rapid improvements, their sales teams aren’t willing to sell differently, etc. So, please forgive me, and go back and read the Outside-In section again, since you were probably ignoring that section as you started planning a great comment about this.
Who knows – a “too big” user story may appear in the backlog for the last sprint within your current release – wouldn’t it be great if you had the choice to release something (valuable) in the current release?
Think about this problem from an outside-in perspective. The smallest story is one that allows a single customer to perform a single task, for which he will pay you.
People Over Process – Conclusion
The objective that every sprint deliver valuable, working software, is not a requirement. It is a design principle of the Scrum process.
Agile is not about mandating processes, it is about getting better and faster. When you can’t reasonably decompose a story into something that can be delivered in a single sprint, don’t. You can have a sprint where you don’t deliver anything, because you only complete part of one thing. Yes, it will look bad on the burn-down chart.
Will it mess with your velocity? A bit. But who cares? Velocity is a measurement that helps inform projected delivery schedules. You may have one sprint with zero velocity, but in the next sprint, when you do deliver the “two sprint story”, you’ll have double the velocity. Magically, your running average is back to normal.
Don’t let the rulers you use to measure the team’s output cause you to act irrationally.
Attributions:
- Thanks to John Loo for the half-a-coin image.
- Thanks to Handige Harry for the puzzle pieces image.
Good stuff @sehlhorst “Don’t let the rulers you use to measure the team’s output cause you to act irrationally.” http://bit.ly/buPF5T
OK, any example can be picked apart, so let’s see if doing it is useful for further conversation.
1) Isn’t defining the clearest set of users/actors something you should do before or while writing stories? If done before, you may have never written the big story in this example.
2) What if defining more user types doesn’t work? i.e. the user in the story does need all the functionality for the software to be useful? What other techniques would you use to address the big story?
dww
Hey David, GREAT questions.
1. Pre-defining personas.
Yes and no :). In my example above, instead of home support vs. IT support specialist, let’s split IT support specialists into groups – one with a ton of people to support, and one with very few people (or only a single location) to support. MAYBE those roles are different enough to justify pre-splitting them into different personas, but likely not. You don’t want more than 5 to 7 personas.
The goal isn’t always to subdivide the persona by “who they are”, but rather “where the value is.” So maybe you split things up by market segment. Banking clerks probably need to do currency conversion, as part of some part of their work. Some clerks/branches would consider that to be critically important, while others may never (or effectively never) do it. A task-centric persona definition would lump the clerks together (probably) into the same persona. When considering the overall market, the product needs to include currency conversion. But for the subset of buyers/users who don’t care about currency conversion (or don’t care very much) can use the product without it.
2. When “nothing works”, have a sprint that doesn’t deliver anything concrete. That’s my escape clause. :).
You can split things based on the subset-of-user approach above, look at supported platforms, operating systems, languages, etc – that sort of thing.
You can also, for (Kano) more-is-better features, introduce the “slow” version now, and the “fast” version update later – if some of your customers aren’t as hung up on speed as other customers.
You don’t want to “do it” now, and “do it better” later where “better” is quality, or user experience. And you should worry about “will having a slow version for a month hurt us in the market?” Balance that against the perfectionist-paralysis mindset of not delivering anything until it is perfect. There’s the whole satisficing thing to keep in mind.
You can also consciously and conspicuously choose to incur technical debt to deliver functionality now, and refactor later. This is dangerous, because none of your stakeholders will be pushing you to pay back that debt until it is cripplingly large and probably way too late.
That enough options? :)
Scott,
I do think there are indeed cases where you have to build a certain amount of underlying structure before value can be realized. There is always a logical build sequence to be considered; you can’t deliver reports on function throughput if you haven’t built the function yet. I may consider the a/c in my car to be its most valuable feature, but it is not what gets built first.
I also strongly agree that delivering too often can cause to much change for a business to absorb without impacting its operations.
Certainly long development cycles of months and months are not acceptable anymore, but some balance between value delivery and cost of change has to be determined for an organization.
@David –
Yup. There’s definitely real rationale for releasing some product updates quarterly or semi-annually. I’ve seen two very solid justifications: cost of change for the customers (to upgrade), and cost of change for the sales team (to update positioning, messaging, training etc).
However, that doesn’t mandate that the product only be released twice a year. You could release monthly, with each customer on a semi-annual upgrade cadence (jumping forward 6 versions at a time). The downside of this approach is the added cost of supporting (ever more) multiple versions of software in the field.
To your point – it is a trade-off each organization needs to make based on their reality: is added cost offset by added value/competitiveness of rapid public releases?
In either case, the team should work on a rapid cadence. I like the model that Google Chrome (and other software products use) – there’s a “latest release” and a “latest stable release” – and each customer can be on either. Obviously, that labeling would be bad, but it may help to have a bleeding-edge-version available to customers who want it.
@David –
On infrastructure before value:
Also agree. But you need less infrastructure for “some of the users” than you do for “all of the users.” You have the option to refactor the enabling-technologies on the fly. When that costs more, don’t do it that way :). It doesn’t always, but I agree – it definitely can.
Thanks again for the great dialog!
@Scott and David,
Using a minimal marketable functionality (MMF) approach limits the impact of changes on users. This approach has you delivering one complete function at a time. This function is complete, rather than minimally viable. Treat the collection of ultimately delivered functionality as a collection of functions, where the functions can be networks of functions.
MMFs enable customers/users to realize some value early. It also allows them to learn a function before they are presented with another function. This is can be consistent with any instructional design related to that functionality. Further, it can be used to move instruction costs from the post-install into the pre-release marketing efforts.
Another way to divide the big user task would be to break it down into a hierarchy of tool tasks, stuff done because it is software, like opening a file, and user tasks, the real work tasks built up of tool tasks.
I really like the below section of the post:
“While these extra development costs are very visible, especially to developers, they are much smaller than the benefits that come from delivering the working software earlier. The cost of resolving bugs increases by orders of magnitude as you move through the product creation life cycle (from development to testing to deployment).”
And this part has clear value proposition even for development teams:
” Getting working product deployed earlier allows you to start realizing value (and therefore revenue) earlier.”
The problem that I see here is, many of the business analysts or product managers (at least those I’ve seen) are coming from engineering background. They usually have a “Feature/Deliverables” approach rather than “Benefit/Value”.
What David has pointed out in regards to building up the infrastructure first, is very valid, however, balancing out the immediate value and future maintenance issues is something which need really experienced people.
Thanks, Alidad, and welcome to Tyner Blain!
My experiences parallel yours somewhat – I’ve worked with very many people on solution teams who approach a problem from their perspective, rather than focusing outside-in from the customer’s perspective.
I don’t know that I’ve met any decent BA or product manager who was feature-fixated, who after having a value-based “see the light” conversation, didn’t embrace an outside-in view of their products and the real-world problems they solve. I always approach this issue with individuals by advocating for the customer’s point of view, in a “think about the problem this way,” conversation. So far, folks have always agreed. I think this is 1% due to my persuasiveness, and 99% due to the truth of my argument. :)
Infrastructure-first is tricky. When you’re not talking in specifics, it becomes a philosophical debate. I try and avoid the fighting dogmas, and focus on the potential value relative to actual costs. If launching 6 months earlier does not generate enough profit to more than offset the (in my experience, much smaller) costs of reworking infrastructure down the road, then build it “right” first. But don’t kid yourself – you don’t really know what “right” is at the start. Regardless, each team has to decide.
The danger of building on fragile infrastructure, of course is a mixture of misreading how things will evolve – your infrastructure may be bulletproof in terms of scalability, but weak in terms of security, when your market requires the opposite. And you may do damage with “not what the market wants” being launched early. That’s not what I recommend :).
Another latent, and perhaps more insidious risk, particularly in larger organizations, is the hard-to-quantify cost of carrying technical debt. It can be difficult (and expensive) to convince stakeholders that what they perceive as “good enough” isn’t. I’ve personified “the system” as a stakeholder, and (alternately) included a member of the delivery team as a stakeholder – to make sure the “keep the system healthy” contingent has a voice.
Thanks again!
In our company we are using a web based service – Manitoo Project Management. It is quite new and is only being released to the public, but we use it with a great success to manage either simple requests from customers or complex long-lasting tasks. We are a team of 5 programmers and thanks to this tool we all know about each other and what are our duties. Or – what are the duties of the others. And we do not need to sit at one office. Visit http://www.manitooprojectmanagement.com to read more. Thanks.
I know we’re on the same page with user stories and that you’ll be able to give me a good answer to my question because of this paragraph in your article:
Perhaps I’m just a little off-course with user stories but I want to know your thoughts are on somehow splitting the one user story across multiple sprints by breaking up the acceptance criteria into incremental enhancements, so keeping the bar low initially to ensure we have functional software at the end of the sprint that story is scheduled in … and technically the user story is fulfilled by meeting those acceptance criteria but not really to the standard our or our client’s brand demands.
For example:
STORY: As a mailman I want to be able to leave mail for residents at an address in a weatherproof box
ACCEPTANCE CRITERIA ROUND 1 (SPRINT 1): Mailman can place mail in a box, mail inside the box does not get wet if it rains, resident can retrieve mail from box.
ACCEPTANCE CRITERIA ROUND 2 (SPRINT 2): Resident can retrieve mail from box without having to use a screwdriver.
Great question, and welcome to Tyner Blain!
Here’s how I approach it: When practical, assure that valuable functionality is delivered with each sprint. When that isn’t practical, deliver the minimum viable valuable functionality in the earliest practical sprint.
Here’s the point – delivering a portion of a story which pedantically still qualifies as a story (e.g. a mailbox, for normal people, which is weatherproof but requires a screwdriver to access) but fails to provide (sufficient) value for anyone is equivalent to not delivering.
You can absolutely take the approach of splitting a story across sprints with incrementally more-challenging-to-build acceptance criteria. But that is an inside-out way of describing what you’re doing. Flip it around to be market-driven (outside-in).
The set of acceptance criteria (easy to access; weatherproof) generally reflects the needs of all target users as envisioned in the roadmap and strategy. Those target users, in aggregate, make up your market. But they don’t all care about the same things. For your example, I’ll propose that I did research and (1) ALL users require non-screwdriver access, and (2) the definition of “weatherproof” is different for users in different regions.
Any mailbox without easy access is unacceptable (to all people in your market). People who live in the desert would be ok with a dust-proof mailbox which isn’t great at stopping the rain – at least for now. So you can split the story by delivering additional acceptance criteria in future sprints. But you need to make sure that _someone_ will get value from the product, so deliver the not-quite-waterproof version for desert users in the first sprint.
There is always some nuance (competitive positioning, risk to your brand, stakeholders, etc). But the guiding principle is the same – if _someone_ doesn’t find value in (this sprint’s version of) the product, then you really haven’t delivered the product yet – so find a different way to split the stories. The goal is not functional software in each sprint – that is the method – the goal is valuable (to someone) software.
Hope that helps!
Yes it does help thank you, I was right in suspecting I was thinking about it the wrong way and instead need to get more specific about some of my user stories.
Starting user stories with “As a user …” is a big no-no, but if you specify a user type and circumstance and then substitute it with “user” and it doesn’t affect the story at all then it might indicate you need to get more specific.
So again with the mailbox, another example might be splitting it into frequency of access … “As a resident who receives mail infrequently” then using a screwdriver might be an acceptable solution, but “As a resident who receives mail daily” has different requirements.
Hmm, yes, back to the drawing board!
Thanks,