User Story Splitting

User stories & Splitting of User Stories

Agile methodologies prefer ‘vertical slicing’ of desired functionality wherever possible.  This means building small increments of end to end functionality that allow the developers to exercise multiple layers of the software – e.g. front end through a middle tier to the database and also allows demonstration of end to end functionality earlier in the cycle compared to some less agile methods.  In effect, software is built incrementally - User Story by User Story.

A completed user story ensures the business has the opportunity of releasing functionality into production much earlier – and more regularly. This has to be the preferred method in most circumstances – compared to, say, waiting until the end of a development when all is released in one big crescendo – or not - as the case may be.

Awarding points only for stories that are 100% complete according to a Sprints definition of ‘DONE’ encourages a team to deliver complete user stories each and every Sprint. One large user story that is incomplete at the end of a Sprint receives no points on the basis that incomplete functionality has little use from a business perspective – and the potential to release some value into production has been missed.

Splitting a user story is one way of ensuring bite size chunks of functionality are built and is usually recommended in the following circumstances:

• When the user story is an Epic -  and therefore too large to fit within a Sprint
• When part of the user story cannot  be estimated,  or is too difficult to estimate
• When part of the user story has a higher priority than the remainder
• When part of the user story is riskier than the remainder 

When faced with the need to split a user story – especially when it is large - the natural tendency of individuals within the technical community like me is often to suggest carving up the development on technical lines – Architecture or Component Centric. But this is usually not the optimum way of delivering business value from a user perspective.

So what options are available to split a user story into smaller chunks that satisfy the business?

• Roles – sometimes a user story is written with a single role shown – but on further investigation it appears that the user story can be split up into multiple roles and therefore multiple user stories. I have seen this on multiple occasions so it is often a quick win to identify user stories exhibiting this characteristic and to break them down according to roles.