“These days we do not program software module by module;
we program software feature by feature.”
— Mary Poppendieck
How to eat an elephant? Piece by piece!
Figuring out when to split
Split it
Divide and conquer once a famous person said. Now it’s you who is in charge. Do it the right way.
There are different ways of how to split a big rock into smaller stones, or how we put it: “How to eat an elephant”. The following section explains you what you should consider and what you should avoid.
What you should do/consider
- Splitting across Data Boundaries [1]
- Split large stories along the boundaries of the data supported by the story!
- Example: Product: Collect financial information
- NOT splitted:
- As a user, I can enter my balance sheet information.
- Splitted:
- As a user, I can enter summary balance sheet data.
- As a user, I can enter categroized balance sheet data.
- As a user, I want the values I enter to be validated so that I don’t make any mistakes.
- NOT splitted:
- Splitting on operational boundaries [1]
- Split large stories based on the operations that are performed within the story.
- Common Approach: split along the boundaries of the common CRUD operations – Create, Read, Update, and Delete.
- Example: “SwimStats Application”
- Not Splitted:
- As a coach, I can manage the swimmers on my team.
- Splitted:
- As a coach, I can add new swimmer to my team.
- As a coach, I can edit information about swimmer already on my team.
- As a coach, I can delete swimmers who are no longer on my team.
- Not Splitted:
- Remove Cross Cutting Concerns [1]
- Consider removing cross-cutting concerns (such as security, logging, error handling, and so on) and creating two versions of the story: one with and one without support for the cross-cutting concern
- Example: “Search Results with Privileges”
- Not splitted:
- As a user, I want to search in the database but just get displayed data based on my assigned roles and privileges.
- Splitted:
- As a user, I want to search in the database and get all results displayed. Note: no cross cutting concerns considered
- As a user, I want to see search results excluded with the data that is not assigned to my user-role.
- As a admin, I want to restrict search results based on the role admin, who can see all data.
- Not splitted:
- Example: “Single Sign On with Username & Password”
- Not splitted:
- As a user, I want to login with username and password.
- Splitted:
- As a user, I want to login with username and password. Note: no cross cutting concerns considered
- As a user, I want a a login form that forces me to enter at least 8 chars long passwords.
- As a user, I want a login form that blocks me from signing in after 3 failed attempts.
- Not splitted:
- Don’t meet performance constraints [1]
- Consider splitting a large story by separating the functional and nonfuntional aspects into separate stories.
- Kernighan and Plauger’s (1974) advice: “Make it work, then make it faster”
- Isn’t that against Clean Code Initiative? No. It’s said to split the performance constraints apart, instead of not doing them at all. Goal is to have a clear focus in every user story so that it can move through the development process fast.
- Example: “Vehicle Search in Stock Pool”
- Not splitted:
- As a user, I want to search a specific vehicle and get the results displayed immediately.
- Splitted:
- As a user, I want to search a specific vehicle and get the results displayed. Note: Make it work
- As a user, I want to get the vehicle search performed in less than 1 second. Note: Make it faster
- Not splitted:
- Split stories of mixed priority [1]
- Separate a large story into smaller stories if the smaller stories have different priorities.
- Running lean: focus on the Minimum Viable Product first [2]
- Example:
- Not splitted:
- As a user, I am required to log into the system.
- Splitted:
- As a user, I have to enter a valid username and password so that I get granted access.
- As a user, I get denied access after entering invalid password three times in a row.
- As a user, I get an email stating that an attempt was made to use the account in every access denied situation.
- Not splitted:
What you should NOT do
- Don’t split stories into their technical tiers [1]
- Don’t split a large story into their technical tiers (like Database, User Interface, Business Logic). Instead, try to find a way to fire a tracer bullet through the story and thus delivering a cohesive subset of all layers of a feature (in German we tend to say “Technischer Durchstich”, can be explained with “Minimum Viable User Story”).
- A Tracer Bullet travels through all layers of a feature. That may mean delivering a partial user interface, a partial middle tier, and a partial database.
- Avoid making large stories larger by including related changes that are not necessary for the delivery of the user story [1]
- Example: Beautifing code, adding this one really unneeded or rare used features just because I am already changing things at this code base
- Exception: Refactoring
- while implementing new features it DO make sense:
- to add more unit tests
- refactor function signatures or structure of the code to make it better readable/understandable
- split away functionality in smaller parts (no class with more than 1000 LoC, follow clean code best practices)
- best practice: if the refactoring itself adds tons of new work, also split apart that refactoring into a new technical debt and plan it for the next iteration (or adapt current planning so that it can be started and done immediately as you are already working in the same code base)
- while implementing new features it DO make sense:
Combining Stories
- With all the advice on splitting stories, it may be tempting to think that every user story should be as small as possible. Wrong. [1]
- Just as splitting stories, combining them can make sense [1]:
- reduce estimation overhead (rather estimating 20 tiny stories, estimating 10 combined stories is faster without lacking of estimation accuracy)
- prioritization get’s easier (rather moving 20 tiny stories around in the backlog, combining them to around 10 stories and prioritize them)
- combing bug reports/defects and treat them as one is very common
Best practice
- having user stories in the size of 2 to 5 ideal days are ideal to flow through iterations of an agile project (assumption: typical iteration length of 2 weeks) [1] [4]
- having a bunch of 0.5-point stories will make you a victim of micromanagement. having a few of 40-70-point stories will lead to over- or undercommitting in the sprint, not really knowing when a software increment can relieably be delivered/produced. [4]
- exception: the ideal size may a little larger for longer iterations (3 or 4 weeks) and respective a little smaller for shorter iterations (1 week) [1]
- velocity of a typical team is usually around 40-60 story points (according to Henrik Kniberg [4] experience) – this would result in around 10 stories per iteration (sometimes as few as 5, and sometimes as many as 15). That is considered a manageable number. [4]
Breaking down user stories into tasks
Divide and conquer, you remember? So my clear answer to this is: Yes, do it!
I am sharing this opinion with Henrik Kniberg [4] supported by enough years of experience in developing agile scrum teams.
Before we go into details, what’s the difference between user stories and tasks?
- User Stories: deliverable the PO cares about
- Tasks: steps that need to be “done” in order to finish the user story and achieve the Definition of Done, the DEV/QA cares about that and has full autonomy in defining them (as long as they fullfill the goal of the user story and don’t break the above discussed Splitting rules)
New teams and Junior developers are typically reluctant breaking down user stories into tasks.
Benefits
The use of iterations are one of the biggest contributions of agile software development. Moving well-sized work packages (aka User Stories) through the development workflow has immediate positive effect on both speed and quality.[3] Do you understand why?
Benefits of smaller user stories are:
- providing of rapid feedback and signaling of incipient problems before they grow large (when Sprint Review are done right and real POs are really attending) [3] The cost of operating blindly – without feedback – is hidden and almost always underestimated. With rapid high quality feedback projects run are less likely running out of control, schedules are more likely to get met and risk is greatly reduced. [3]
- better testability – acceptance criterias are defined automatically with the smaller user stories (see examples)
- faster progress, lower lead time
- better estimation accuracy
- better documentation results (based on clearer written user stories)
- software architecture follows the user stories (which can be sometimes good and intended, sometimes not, be cautious)
Additional Aspects
Additional aspects worth to think about:
- User centered design
- Putting the user in the center of our focus aims for the most important things the user really needs in order to accomplish/reach a certain goal
- It helps figuring out what’s really mandatory and what’s nice to have
- You can read a lot of books about it:
- …. (book list will be provided soon)
- Purpose – Understanding the bigger picture
- The team understands WHY we have to implement something: the quality of the result will therefore automatically increase, errors will happen less likely
- The team will grow it’s motivation when there is a clear purpose of WHY we need a feature and what GOAL can be reached with that by the user
- Best practice
- Remember the best practice of writing user stories?
- As a [ROLE] I want [FEATURE] so that I [GOAL/BENEFIT]
- Remember the best practice of writing user stories?
Methods
Training & Feedback
- Training Examples
- Split Story:
- As a car dealer, I want to sell a car so that my client is happy.
- Split Story:
- Discussion
- Think of your current project: what are some user stories that you found difficult to split? How might you split them now?
- What problems do you think are caused by splitting a user story?
- Need feedback? Use our Online Tool for Training:
- send us your original/splitted User Stories
- we will review them and provide you with feedback
References
- [1] Agile Estimating and Planning; Mike Cohn; 2005
- [2] Running Lean – Iterate from Plan A to a Plan That Works; Ash Maurya; 2012
- [3] Leading Lean Software Development – Results Are Not the Point; Mary and Tom Poppendieck; 2009
- [4] Scrum and XP from the Trenches – How we do Scrum; Henrik Kniberg; 2007