Writing user stories for agile software development can be a challenge for any Product Owner. Stories are supposed to deliver business value. What’s that? Stories are supposed to be vertical slices. Slices of what exactly?
At times, we get overly bogged down in words and their definitions. We take things too literally and get stuck. User stories are a simple concept. Let’s keep it that way. Take this example.
Sort a Random Collection of Data
Let’s say your software application gathers an assortment of textual data (let’s call it motley data) that might be interesting to end users based on some specified criteria. It works and the users have asked for the ability to sort the data.
As a data analyst, I want to sort the motley data so that I can more readily find items of interest to me.
Sounds simple, right? Not so fast. Let’s say the data consists of text, numbers and dates. (Forget pictures, sound and video. That would be over-the-top difficult.) Here are a few problems to ponder.
- Text – Should upper and lower case letters be sorted together or separately?
- Numbers – Are 01 and 1 the same number? What about 0.56 and .56? Should numbers be sorted before, after or along with text?
- Dates – Should 6/1/12, 06/01/2012 and June 1, 2012 be sorted as the same value?
What appeared to be a simple sort algorithm could become multiple complex algorithms — far too much to be considered a single user story. In addition, the user interface needed to control the sort will present its own challenges.
Many agile teams would be tempted to break out the UI as a story, perhaps using it as a way to drive the implementation. But, a UI that does nothing has no business value. If the UI is implemented but only a few things actually work, it will confuse and frustrate the users. If algorithms are implemented without a UI, how will the users control the sorts?
See that! Stories don’t work! Not everything of value can be delivered within a sprint!
Hold on. The original user story grew. It became an epic. Epics consist of multiple stories. Our goal is to deliver complete stories within each sprint. Epics may take several sprints. We can do this.
Here’s one way to proceed (not the only way, but this could work):
Define several user stories that will make up the epic. For example,
Epic: As a data analyst, I want to sort the motley data so that I can more readily find items of interest to me.
Story: As a data analyst, I want to define criteria for sorting the motley data so that I can more readily find TEXT of interest to me.
Story: As a data analyst, I want to sort the motley data so that I can more readily find TEXT of interest to me.
Story: As a data analyst, I want to define criteria for sorting the motley data so that I can more readily find NUMBERS of interest to me.
Story: As a data analyst, I want to sort the motley data so that I can more readily find NUMBERS of interest to me.
Story: As a data analyst, I want to define criteria for sorting the motley data so that I can more readily find DATES of interest to me.
Story: As a data analyst, I want to sort the motley data so that I can more readily find DATES of interest to me.
Now we have six user stories. From an implementation perspective, three focus on the UI and three focus on the sort algorithms. From a functional perspective, there are three pairs of stories and each pair focuses on a data type. (You might choose to break this up differently and/or add more stories. That’s okay too.)
Depending on the size of the team and other factors, these six stories could be implemented in one, two or three sprints. Each sprint would deliver real business functions (a.k.a. value).
Also note that you might decide to build out the entire UX in the first sprint. If so, simply hide UI elements that are not yet functional. You can expose those elements as the underlying algorithms mature.
Bottom line: Think of stories as descriptions of software features that taken together as epics provide meaningful business functionality. Don’t get too caught up in the individual stories. These will often be too small to be meaningful. Also, don’t just think in terms of sprints. Consider using releases as the delivery vehicles of tangible business value.
Interesting post. I think this is one way of handling the story problem but it shows how contrived the stories must be.
In your example, the stories are not complete since the criterion arent defined. In addition they arent complete stories since some are ux and some are backend.
The solution? In my book – don’t use stories. Use tasks. Stories can be there for very high level things but break them into tasks…not stories.
Of course that’s not the “agile way” but then again I think that much of the “agile” way is impractical outside the lab.
Cheers,
jordan
I haven’t read your book though the approach sounds interesting. I like to get people to think about issues in broad terms and not get boxed in by dogma. In the end, the key point is to break up large blocks of functionality into smaller chunks that can be delivered quickly. Thanks for sharing your ideas!