How to Split Story Points Correctly as a Project Manager
A contentious issue is the task of splitting a User Story, during a sprint. As a Project Manager, you sometimes find the necessity to break-down a user story into multiple smaller ones, when it is in fact too vague, or too large to fit a sprint.
Based on re-prioritisation, you find that your User Story could not fit within the single iteration and deferring it in it's entirty to another iteration doesn't make as much sense, considering it will stuff up the complexity estimate of the subsequent sprint. In another example, you have estimated a User Story inacurrately at the start of the project, perhaps because it was difficult to put an estimation point because of a lot of uncertainties. You would want a part of the User Story of functionalities but perhaps can defer others.
You therefore need to concede that splitting the story is the only logical conclusion. So How to Split Story Points Correctly as a Project Manager?
Logical division of a User Story
There are a few ways in which you can further breakdown a User Story, so that you maintain the integrity and encapsularity of the entity whilst reducing the complexity point estimation.
Let's say you have an Epic User Story consisting of As a User, I need to Authenticate myself before accessing the App. Thinking about this user story, you would deduce the following technical functionalities:
- I need to log-in using existing credentials that would authenticate & recognize me
- I need to register as a new user providing new credentials, which would authenticat & recognize me
- I need a way to retrieve my password if I am unable to recall my existing credentials that would authenticate & recognize me
There are a few sub-user stories there deduced from that primary one and collectively does seem like rather a complex User Story. For a sprint, we may require only to demonstrate one or two of the three sub-user stories, and working on all three collectively may be too large for the iteration.
Functionally, we can then break down the initial User Story into two User Stories, As a new User I need to Authenticate myself before accessing the App and As an existing User, I need to Authenticate myself before accessing the App. You have therefore reduced and divided the complexities between two new User Stories, making it easy to separate them into two sprints.
This one is probably my favorite of the two, splitting a User Story based on the competency of the team. That is, this separation process involves breaking up the User Story across the technical division of labor involved in the User Story. Using the example in the previous process, As a User, I need to Authenticate myself before accessing the App, we would divide it into the UI component and server component.
We would therefore deduce having As a User, I need to visually authenticate myself before accessing the App and I need to authenticate User credentials via the Server. The first User Story would advocate working on the UI controls whilst mocking the interaction with the server, producing the minimum prototype of the User Story.
The second User Story would complete the features requirements by focusing on replacing the mocked data between the UI and server with real API calls. What I like about this method is that it does not create any cross-dependencies between the User Stories, as in good Model-View-Controller designs, the coding separation would reduce the chances of code-space conflicts. We also get the added benefit of an MVP UI, a Lean Development that allows us to demonstrate something even though the back-end is not developed yet.
In Mike Cohn's book, Agile Estimating and Planning (2005), the author points out the risk of cross-cutting concerns, whereby you would have security and error-handling which work across various User Stories. For instance, error-handling and logging would apply across many User Stories, not just the Registration section, and removing such orthogonal features by separating that from the actual User Story would allow for a reduction in estimated story complxity, thus promoting the possibility that the User Story may now fit within the iteration.
Mike Cohn did warn in another section of hte book against Splitting a Story into Tasks which he based on the hypothesis of Hunt and Thomas (1999) which talks about the ability to fire a tracer bullet through the story. I am not convinced that this is a complete 'No-No', as it depends on numerous other conditions and facets of the project. That is why I presented two methods, the Functionality and Competency options, both of which I would stand by as valid.
The first method is synonymous with being able to fire a tracer bullet through it, but the latter one promotes the Test-Driven-Development methodology of mocking data (giving you enough time to do that) whilst providing a complete UI that can be signed off by the client. I would be happy to see if other PMs have thoughts and experiences to share on this matter, but this is my way of splitting story points in a tightly-sprinted project.