Writing independent user stories seems simple, but it is actually difficult to do well. There are often parts of some stories that are dependent on other stories' functionalities, so it's not easy to keep them separated. Kris Hatcher relates how his team wrote and scored stories to keep them independent but still meeting acceptance criteria.
When it comes to requirements, some teams have difficulty writing user stories that fit their specific necessary parameters.
The last team I was on, we had to fit our stories into a two-week sprint and make sure they each delivered value to our product owner, among a variety of other specifics. We kept struggling until our ScrumMaster introduced a mnemonic to help us remember a framework for writing stories. All we had to do was "INVEST" and make our stories:
Independent
Negotiable
Valuable
Estimable
Small
Testable
On the surface, this seemed easy; as we dug into the acronym and started applying each bit, however, we discovered that it was much more difficult than it sounds. We found the “Independent” portion especially challenging, so we decided to experiment with how we applied that to our story-writing exercises.
Writing independent stories seems like a simple task, but it is actually really difficult to do well. The application we were working on had several reports, and we often implemented functionality on all of them, such as adding the ability to export the reports to Excel files.
Before we learned the INVEST trick, we would have written a story to implement the export to Excel functionality on one of the reports, then written separate stories for each of the other reports, each of the successive stories having a dependency on the first one being completed. If we are writing stories to be independent, that cannot happen. So, our first attempt to do things independently was to write, and score, each story so that it contained everything necessary to be completed.
This worked well for the first story in the group, which was ranked by our product owner. However, the remaining stories were then taking much less effort to complete than we had initially estimated, because the first story laid the groundwork for the rest of them.
As we talked about this issue and looked around for ideas and inspiration, our next attempt was to write two stories. The first one would implement the feature in question on one report, and the second one would implement the same feature on all the remaining reports.
The story card was left with a blank area for which report would be the first one, which our product owner would fill in when she selected that story. We would score those two stories, typically with very similar scores, keeping in mind that the first instance would be much harder because it would influence the other implementations coming after it.
While in theory we thought this would work well, in practice we found that our product owner rarely wanted to implement the functionality on all the remaining reports at the same time. We decided to see if there were any other ways to keep our stories independent and score them accurately.
That discussion resulted in the idea of “double scoring” our stories. We experimented with giving stories two scores: one for if it is played as the first one in the series, and another if other stories in the series are played first. In this scenario, we would write a user story for each instance of the new feature—say, one for each report—and score them the two ways.
We typically spend a little more time discussing these stories during grooming so that we have a better idea of what it will take to complete them. Then we score them once as if it were the first time we were doing that story, then again, this time imagining we have already completed one of the other stories in this particular sequence. On the score section of our story card template, we write the score as a fraction, showing the first story score on top and the subsequent story score on the bottom.
This way our product owner has the ability to select whatever story she wants based on where she feels she will see the most business value, and we do not have to re-evaluate our scores after the first story is played. We also do not have to adjust our acceptance criteria, because the functionality they lay out will need to be in place regardless of when the code was written.
Initially, we were concerned that the "subsequent story" score would be incorrect due to the lack of knowledge about the final solution, but we found that these estimates were actually pretty close to the work that it took to complete the story. So far, the experiment seems to be working for the team. There are still some bugs that need to be worked out, but we have decided to keep this practice going for the foreseeable future.
I hope you will be able to use these ideas to help your team develop better stories that can be played more independently!
User Comments
I'm not sure I see how these stories are dependent on one another. They seem to be dependent on a particular feature common to all of them. None of them, regardless of which one is selected, can be completed without that feature existing. But they are not dependent on one another since, as you point out, the PO can pick any of the three desired to go first.
I usually think of stories being dependent when you cannot do one without doing the other at the same time, i.e., within the same iteration. This does not seem to be the case here.
Scott, you are correct that these are dependent in that they require a shared piece of functionality to be completed before they can all be delivered. In this scenario, before we played with the INVEST trick, we would have made one story larger than the others, and then required the PO to pick them in a specific order based on our choices not on their needs.
In more complex cases, where you need to develop complicated functionality that's to big for a single story, we've found that we can still divide things up in to smaller stories and that doing so yields a more successful project overall. In most cases, you still can't release the functionality to an end user, but allowing the PO to see things as they progress means that you get feedback on the development of complex functionality without having to complete the whole thing and potentially wasting time working on something that isn't in line with the PO's expectations or needs. In addition, by writing independent stories, we can stop working on the functionality if an urgent business need comes up without having to leave a story partially done and forget where we were when we come back to it weeks or months later.