The topic of feature (or User Story) size is usually a surprising one for teams that are new to Agile. Teams are frequently used to working and releasing very large user stories. Although there is no definite “correct” size for a user story, my vague rule of thumb is that User Stories should on average be about half a day to a day of work (for a programmer). This means that for a team with five programmers working 10 day sprints, I would normally expect to see about 50 – 100 User Stories in a Sprint. Wow!
The Benefits of Small User Stories
Typically, teams adopting Agile will work with large User Stories to begin with and break them down into small technical tasks. The User Stories are typically relatively estimated using Story Points. The team would then do hour estimates for the technical tasks and have a burndown chart that burns those hours down.
I prefer to have a large number of small user stories. This is because it makes User Stories:
- Easy to track
- Easy to grasp
- Easy to work out done
- Less scope creep
- Easier to estimate accurately
- Same size
- Less estimating
- Easy to merge
- Easy to test
- Easy to release
- Rapid response to change
The key to all of these benefits is FOCUS! Smaller User Stories let the team focus like a laser beam on what is important (thanks to @pavlakis for clarifying this in my mind!).
The Value (the difference or ratio between cost and benefit) of software is in completed User Stories, not in completed technical tasks. Customers do not care that you have set up SQL Server. They care that they can login.
Tracking the value delivered using a burndown chart is more useful to a business that tracking the technical tasks. Teams with a large number of small stories can burndown Story Points for User Stories instead of burning down hours for technical tasks. This means the team is focussed on delivering value rather than focussed on working on technical tasks. This also has the happy side effect of making the team want to finish a User Story rather than the team “siloing” and saying “I’m a programmer, I don’t do testing. He does the testing!”.
It is EVERYBODY’S job to get the User Story done.
Easier to understand
Smaller User Stories are also easier to grasp and understand than larger User Stories. This means that the developers and testers are much more likely to build the right software on the first attempt than if they are trying to build a large and complex User Story.
Know when it’s ‘done’
Following on from this, it is also easier to work out when a small User Story is “done” than when a large User Story is done. There is simply less room for “grey areas” of uncertainty. This also means that there is less scope creep on small User Stories. If a small User Story is well-defined, anything not included in the User Story description is simply another User Story! It is common for large User Stories to take more than one or two Sprints to complete. This makes the Story Progress very hard to track and predict completion.
Easier estimates
Small User Stories are also much easier to estimate accurately than larger User Stories. Take the “hour” estimate example. Is it easier to estimate a one hour task accurately or a 100 hour task accurately? Pretty much everyone I have ever worked with would say it is easier to estimate the smaller task more accurately.
Common sizing
As User Stories get smaller, they also tend to assume a common size. This is very common in Agile teams that have been working together for a couple of years. The User Stories reach a minimum size which seems to be reasonably common regardless of the functionality required in the User Story. Those of you who practice Lean software development will recognise this common sizing as an important part of creating a smooth workflow.
Less onerous
In addition to estimating becoming more accurate, it also become a less onerous activity. Teams who have small User Stories tend not to estimate technical tasks. This means they do significantly less estimating. It is worth noting that teams usually report a very stable velocity in terms of Story Points and wildly varying hour estimates for technical tasks! This means that those teams are putting a lot of effort into being wrong about hour estimates! The simple solution is not to do hour estimates and just use the more accurate Story Point estimates instead.
Easier to merge
From a technical point of view, lots of teams do a lot of branching and merging (which I hate). It is far easier to merge a small unit of work than it is a large unit of work. Interestingly, the smaller a team’s User Stories are, the less they feel the need to branch which in turn means they waste far less time doing complicated merges!
Easier to test
Smaller User Stories are also far easier to test than large User Stories. Since the scope of the work is so much smaller, it is much easier to who that a User Story meets its acceptance criteria. This drives up the overall quality of the software. It also means that EVERY User Story can be finished with NO BUGS of any severity whatsoever!
Easy to release
Small User Stories are easy to release. Lots of teams are surprised when I say that I do two or three production deployments every day. They are even more surprised when I tell them that the Product Owner releases the deployments using a console we have built for him! Our Product Owner never has to ask us to deploy work to Production – he just does it himself when he is happy with it! All of this is much easier to achieve if your User Stories are small. Large deployments give large deployment problems. Small deployments give small deployment problems!
More responsive
Finally, building smaller User Stories allows a team to respond to change more rapidly. I would always encourage team members to finish the job on front of them before moving on to a new job. If a team member works on small jobs, when priorities shift, they are more likely to become more available, more quickly to work on a new high priority.
Nick is the CEO of McKenna Consultants Ltd, based in Harrogate, North Yorkshire, UK. Nick is 1 of only 6 Certified Scrum Coaches in the UK. McKenna Consultants are a professional team of computer programmers delivering the highest quality software specialising in a broad range of technologies for windows, web-based and mobile applications, including apps for the iPhone, iPad, Android and Windows Mobile. McKenna Consultants also deliver Agile coaching, consultancy and training to organisations of all sizes. For more information on the services that Nick and McKenna Consultants provide, please visit: https://www.mckennaconsultants.com/
