A case against splitting User Stories

Often we encounter a story that is too large to fit into a sprint. So we go ahead and try to split the story. And since most of us are not User Story ninja’s the divide is often “artificial” – i.e. it’s demonstrable with certain caveats – the real value is delivered when all stories in the split are complete.

These artificial splits often result in a backlog that is littered with stories that do not provide coherent functionality on their own. Even worse, we end up with “Cut and Paste” blocks of story narrative – adding no new information to the backlog at the expense of clutter and complexity. My question is, if the original decision to split them was to have them fit them in a sprint then why don’t we “join” in the following sprints?

How about not splitting the story but documenting the current and future scope for the story. The Product Owner/Team agrees on what the current scope of the story is for this sprint and in the later sprints more and more future scope is brought into the current scope until the story is truly done. This current and future scope can be defined as acceptance criteria. The idea is that we achieve a demonstrable scope for the current sprint without having to split the story.

To best situation is where we have well defined stories that fit into a sprint and if we can maintain this when splitting stories than that’s the place to be. However, if you feel that you are unable to create two distinct stories by splitting one then this is a possible alternative.

Project Estimates

In my previous post on High Level Project Estimates, I talked about 3 points estimates to help provide an up-front estime of effort for a project. Aside from the effort estimate you also need to consider other aspects that the team will spend time on. The following are some aspects I consider with the kind of percentages (above the effort estimate) I have experienced. Note: these percentages are by no means standard or the norm they are essentially a rough guess based on the projects I have worked .

  • Planning Meetings @ 10%
  • Demos @ 2%
  • Code Reviews @ 5%
  • Retrospectives @ 5%
  • Dark Mater @15%
  • Bugs @15%
  • New Technical Stories and Spikes @ 25%
  • Change Requests (shouldn’t average more than 15%)
  • Holidays and Sick Leave @ 5%

You will also need to consider Management Overheads as well as Business Analysts (if included in the team), QA/Functional Testing, Support and Maintenance (if required).

Defining and Prioritising a Backlog

What is the best way to review a backlog? How do you ensure that it is “complete”? How do you ensure that the prioritisation reflects the business vision and goals?

When first faced with a backlog, you are often overwhelmed by the long list of userstories. The most important step is to set a context for these userstories. Are these userstories organised in a hierarchy of “epics”? This hierarchy will help set a context. But first we need to understand what these epics mean at the highest level. Do they represent a user’s high-level goals or are they merely there as a container for some loosely related stories?

When reviewing a backlog for completion it is vitally important that the stories are defined in a context. The context can take different forms depending on the nature of the application. For example if an application has a clear high-level flow that the user journeys along then the epics may be defined as activities in this flow and the userstories can be grouped under each epic representing the functionality required for this activity. This article by Jeff Patton presents such an approach. However, your application my exhibit a more random usage scenario. In this case epics representing high-level user goals may represent the best context for the stories. You can also provide references to other artefacts such as user journeys/wireframes to further enrich the context. This article by Scott Sehlhorst is an interesting discussion of setting a context for user stories.

This grouping of userstories by a context also helps to manage their prioritisation. You can individually prioritise stories within each epic and then also prioritise the epics. Note that just because one epic has a higher priority does not mean that all its child userstories are of a higher priority. You may discover that only the first few userstories can provide enough functionality that further work on that epic is of a lower priority then working on another epic.

The relationship between Product Owner, Business Analyst and Tester

In an Agile/Scrum team the Product Owner manages the Product Backlog, a Business Analyst may help further elaborate the backlog. Acceptance Criteria is “one of the” or the output of that elaboration. A Tester may futher define the Acceptance Criteria and write test scripts to verify it. What is the relationship between the three roles? Inseparable, acquaintance or in a love triangle?

My thoughts spring from the fact that I have frequently seen a gap between the tester and BA/Product Owner’s understanding of the requirements. I accept that the BA comes from the business perspective and the tester from the system/specification perspective. How can the two reach the same understanding of what the end system will deliver?

Using JIRA for Agile Project Management (without Green Hopper)

Jira from Atlassian  is a very popular issue tracking software and can be quite effectively used for Agile Project Management. Jira has a plugin (Green Hopper) that allows for creation of a backlog, iterations and tasks.  However, with help from the free Mylyn plugin for Eclipse I was able to setup a Product Backlog and Iteration Backlogs.

For the User Stories in the product backlog I created two issue types (Epic & User Story).  Story hierarchies can be represented using Jira Links.

Note: Currently Jira connector in Mylyn has an issue with the “depends on” and “is depended on by” relationships. It displays them the wrong way around in the Tasklist hierarchy.  You can keep track of the following issues to see if they’re fixed: 255680, 223151.

For Iteration Backlog I created a version for each iteration and assigned the stories to that version/iteration. Each leaf story can then have Jira Sub-tasks to represent the tasks in a particular iteration. The Resolved state of the story is used to mark it complete and Colsed state is used to mark it as “accepted”. You can use Mylyn to see story hierarchies, also I found Mylyn to be a much more intuitive interface when working on Product and Iteration backlogs.

Userstories and when enough is enough

Perfection in software is impossible. Software developement is subject to the Law of Diminishing Returns . So how do you decide when enough is enhough?

In a recent presentation Al Goerner discussed catagorising stories. Two of the more interesting catagories were “New feature” and “Feature enhancement”. In an Agile project where new stories are constantly being added to the backlog, these two catagories can help use decide when a product is maturing and the new stories coming into the backlog are simply tweaks to the original requirements. In general “Feature Enhancements” provide a much smaller “bang for your buck” then “New Features”. A simple rule of thumb is that when your backlog is mostly “Feature enahncements” then it is time to re-evaluate the ROI for continuing developement and compare it with the opertunitiy cost of a new endeavour.

Catagorising stories can also help us manage Risk and Issues within our backlog.