The Elephant in the Dining Room
There is a famous saying, “How do you eat an Elephant? Answer: one bite at a time!” and so it should be when developing software features. The challenge however is that people do not always recognise a metaphorical elephant when they see one. When faced with an epic or large user story, they think, well that looks easy, no problem, just let me get stuck in. Sometime later, it turns out that the story was more complex than originally thought and is actually going to take a lot longer than originally envisaged. The outline of a large grey pachyderm is slowly coming into focus and trampling all over the sprint or project.
Software Development is an empirical process that relies on constant and rapid feedback, i.e. learning. Big fat stories do not encourage this. Some key things we learn when developing a user story are:
* are there any technical challenges?
* is it a lot more risky than we anticipated?
* did it work functionally e.g. no technical show-stoppers?
* is the development cost prohibitive?
* did it work non-functionally, e.g. performance, scalability, security, etc?
* does it provide the value we envisaged?
* do customers love it?
* does it integrate well with the rest of the product in practice?
If a big fat story takes say 30 days to build, test and deploy then that’s a long time to wait for answers to questions such as those above. Breaking down such a 30 day story into say 5 x 6 day stories (even if it actually adds up to more in practice) is far more desirable as every few days you will be getting answers – you will be learning. Some of those answers will be good, some will be bad. Some will be totally unanticipated, i.e. answers to questions you never thought relevant before you started. Such learning is worth it’s weight in gold. It provides you with options early and frequently which may guide you to adjust course, pivot or abandon the goal all together.
A related concept here is that of fail fast. This is often quoted in the context of innovation. All software development is innovation to a degree. Pretty much every piece of software developed is unique and has never been done before. If a course of direction is going to lead to failure, then you really want to detect this as soon as possible and fail quickly. The phrase should really be be “If you are going to fail, fail as soon as possible and do it quickly”. Small user stories support this strategy, or risk mitigation strategy, much better than big fat user stories.
Failure sounds dramatic but may manifest itself as the user story far exceeding the original development budget (cost-benefit); encountering a technical limitation during implementation that undermines the entire epic (or big fat story); user feedback during demo or actual use is far less flattering than expected; quality of the software is very poor as too much was attempted in too little time.
Consider a backlog comprised of 3 big fat stories. The stories are ranked as follows:
That is, B is expected to deliver the greatest amount of value or is the most urgent to get into the hands of users. C is actually very close behind but is definitely in 2nd place. A is in 3rd place. The team works on these stories in this order, i.e works through the backlog.
Now suppose the team delivers B and then runs out of time 70% of the way through C. Users are able to start using B but not C as it is an incomplete state and not a state that can ship. Story A has not even been started.
C << Team runs out of time 70% through this story
Now consider the case where a shrewd development team and Product Owner break these stories down into small stories. Let’s say A is broken down into A1, A2, A3, A4, A5 and similar breakdown for B and C. The ranking of these stories may result in something that looks like this:
C4 << Team runs out of time here
Contrast with the scenario of 3 large stories. In the case of the smaller stories, it becomes apparent that not all elements within B are of higher priority / ranking than all elements of C. In fact, it makes much more sense to implement the really valuable or urgent parts of all 3 large stories, i.e. Epics, with the same amount of effort it would take to deliver the whole of B and 70% of C.
The sum-total of value delivered is greater when the stories are broken down and ranked at this more granular level of detail. Also, you have learned a lot about A, B and C which you can exploit when implementing the remaining stories for A, B and C.
It’s often quoted that a large percentage of software product features are rarely used. Consider again the example:
C4 << Team runs out of time here
In other circumstances the following may be a wise outcome:
C4 << Team chooses to stop here as enough value delivered
The team learned that user goals are actually fulfilled sufficiently at this point and that completing the remaining stories of A4, A3, B1, B4, A5, C2, C3 is no longer justified or they slip much further down the backlog.
Any software development endeavour is dominated by the 3 dimensions of Cost, Schedule and Scope. The agile approach is to pin down Schedule, i.e. time-box; pin down Cost, i.e. have a stable team for the duration; and use Scope as the key lever by which the first two objectives can be honoured. That is to say, by allowing variance in Scope, the given team can achieve the business goals in the desired time-frame. Like the above exploration of sub-priorities, there is sub-scope. In other words, it is usually far more desirable to shave a little scope off one or more of the expected features than it is to drop one or more entire features. Small user stories help you to think this way from the outset and help you to provide yourself with such options. Options are good.
It’s also worth noting at this point that user stories focus on outcomes and user goals without specifying how those goals are achieved. Again this gives you more options. As a <user> I want to <achieve goal> So that <benefit>. Again this gives you some wiggle room in scope space if you set up the expectations with the customer, client or users appropriately. You want some flexibility around the solution. As long as the outcome of the user story is delivered then you can be smart and pragmatic about how that can be best achieved within the constraints of Cost and Schedule.
We’re in this Together – aka ‘Limiting WIP’
A big fat user story can give the misleading impression that members of the team are working on the same thing, together at the same time. They are all working on the same story, sure, but because the story is large each member of the team is focusing on a separate part of that story.
Small, slim stories encourage the team to combine forces, to collaborate, pair, share knowledge and drive value through the delivery pipeline together, you might say as a team!
As well as thinking about the size of the story, the way that the story represents a bite out the larger feature is also important. You should aim for a story to be a vertical slice through the system in order to deliver ‘working’ value. For example, for a product built with a front-end and a back-end, the story should aim to incorporate the necessary elements of both in order to deliver customer value. To be avoided is slicing stories such that one story delivers the front-end functionality and the back-end elements are delivered in another story. You should note that this approach breaks the INVEST principle of being independent. That is, the value of the story depends on the other story. If the backend story was not delivered then the front end story has precisely zero value!
The vertical slice pulls together the frontend and backend developers so that they focus on delivering incremental value. This also reduces risk of the two becoming out of step in terms of design, implementation and ultimately, quality.
Effectiveness versus Efficiency
A common objection to splitting big fat stories down into nimble, slender ones is that developing software piecemeal is simply not efficient. Splitting a story down takes effort which could be spent writing code. Taking a feature through to a shippable state with all of the stages involved in doing that multiple times instead of just once is surely a waste of effort, time and money?
Let’s consider again an example mentioned previously. Say a story is estimated to take 30 days to complete. Alternatively we split that story down into 5 small stories of roughly equal size. The argument against doing this would say that this would most likely result in 5 x 7 day stories. So overall the smaller stories take a total of 35 days. So a waste of 5 days.
Looking purely through the lens of efficiency this makes total sense and would lead any sane person to choose the big fat story.
However, this is a myopic perspective. It does not take into account the following strong forces at work in developing software:
– the World and our understanding of it are very prone to change
– software development is a very risky business
- imperfect communication
– human communication is largely flawed and a very poor substitute for working software
- human optimism
– we tend to underestimate effort, risks, unknowns
- human ignorance
– stated with empathy; you cannot know everything before you start
- estimation inaccuracy
– which increase with the size of a story
Take any one of the above and it alone most likely outweighs any consideration of efficiency. Take a few of them, which almost certainly apply in any software development endeavour, and suddenly considerations of efficiency pale into insignificance. Developing software as a series of small stories has a significant impact on addressing the above listed forces (each one being a topic worthy of their own article).
It should also be doubly pointed out that that big 30 day story is in itself more than likely going to take longer than that, further eroding the efficiency argument.
Of course, this is not to dismiss efficiency. There is a constant fight to be had to combat impediments and more generally the 7 wastes of software development (Lean – Poppendieck). Here we are just talking about the inefficiencies associated with splitting a big story down into small stories and developing them this way.
In addition, you will find that teams get really good and really efficient at tackling small stories. Small stories can provide greater focus and impetus as the next goal is almost always within grasp rather than being weeks away in the future. Lots of small wins are also good for team morale which also boosts team performance.
Small is Beautiful
If you were not convinced before reading this of the perils of big fat user stories and the merits of splitting them down into small ones then I hope this article has inspired you to explore further and give it a try with your team. There are some good articles to be found on strategies for splitting down stories. It does not come easy to everyone and is something you get better at with practice.
- Mike Cohn – User Stories Applied
- Gojko Adzic and David Evans – Fifty Quick Ideas to Improve your User Stories
- Christiaan Verwijs – 8 useful strategies for splitting large user stories (and a cheatsheet)