A great article on User Stories vs. Use Cases. Credit: http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
A good Product Owner, as custodian of the backlog, needs to be cognisant of the importance of constantly improving their writing skills in order to craft the best possible user stories. Key to this is understanding what the purpose of the one or more entities in the backlog is and how to categorise items as such.
Here's where I've found quite a bit of confusion. Thus, I outline my perspective and recommendations.
There are two (at a stretch, three) entities I'd recommend are useful for the Product Owner to enshrine in the backlog. That said, a good Scrum Master will help to localise these for their team(s) to ensure a fit for the organisation.
They form a single heriarchy of many-to-one: Epic (bucket) -> User Story (unit of value) -> Tasks (unit of tracking)
The "conceptual bucket": This is an entity used only for linking units of value together. It is of no direct use to a Scrum team. It would be the primary unit that the end user (or the business client) is concerned with, and never needs to be more than a few words long, e.g. "Marketing Module", "Profile Pages", "Product Search". A product owner may elect to add further detail (where needed by the customer and/or end user) by crafting them as epics or scenarios and adding acceptance criteria against these. I've heard this type of entity variously referred to as "Themes", "Epics", "Components", "Conversation cards", "User Scenarios", or even "Oh dear that's a big story we should probably break that one down." The "conceptual bucket" contains as many "units of value" needed to deliver them as required.
Protip: in the Atlassian JIRA/Greenhopper tool, these would be "Epics"; and Target Process, these would also be the "Epics" entity. Rally provides a parent-child user story hierarchy - I do not recommend letting this hierarchy getting more than three deep (ideally less), as it becomes difficult to understand quickly.
The "unit of value": There are one of these per smallest possible unit of value to the customer. If there are multiple steps to deliver this unit, and those steps are not of value by themselves, then they are units of tracking. If those sub-steps are of value one their own, then they are each unit of value and it can be further broken down. The original entity then is a possible candidate as a conceptual bucket. These are what I consider "user stories", useful for a scrum team to track on visual management boards and deliver against each sprint. Its purpose is to indicate value delivered to the customer and this value is measured in points.
The "unit of tracking": For tracking the "doing" of a task. This may be because:
- individuals want to allocate themselves to sub-components of the story on behalf of the team
- the team has yet to cross-skill, thus there still is a need for specialist tasks
- the organisation wants to track time (perhaps for time sheeting purposes)
These have some usefulness to the team; and I believe that their value diminishes with increasing Agile maturity. These become less important as:
- stories get smaller in size
- as teams become more cross-skilled and capable of delivery of entire user stories in pairs (or otherwise)
- as points and the burndown chart become more central as the metric and measurement system.
Do you like this approach? Do you have a different one that works? I'd love to hear from you.