That's Not A User Story, That's An Epic!
by Kelly Waters
When putting User Stories onto a Product Backlog (or feature list), you shouldn't feel compelled to break everything down until the features are nearing development.Further down the Product Backlog, it's fine for items to be fairly fuzzy. It's also fine for items further down the backlog to be whole projects - large, high-level items that are not so much User Stories but more like Epics!
As an item nears development, the item should be broken down further. And as it nears development, the item on the backlog should be defined in sufficient detail that the team can reasonably estimate its size and break it into tasks.
Until that time, however, it's just really a placeholder. A reminder for prioritisation and high-level estimating. That's all.
For some people, particularly those used to a more traditional project approach, used to detailed specifications up-front, this can potentially feel very uncomfortable. It shouldn't.
The logic here is simple. There is little point defining a feature (or set of features) in detail if it may never reach the top of the priorities. The other aspect of this logic is that you tend to know more about your requirements, constraints, etc as time goes by.
And things change. People come and go. Sometimes the team has changed significantly since the original requirements emerged, so information can be lost if it is captured too early.
Therefore it makes business sense to defer details until they are needed.
11 February 2008 17:44
makes sense....my experience has been that we do a big detailed design up front and then as we develop it, things change! And then no one feels like (or has the time) to go back and update the huge word document and UML diagrams to reflect all the little changes.
11 April 2008 01:43
As someone new to Agile (scrum) and a product manager by trade, I'm concerned about how I can employ user stories to convey requirements. I think the biggest failing of traditional product requirements crafted for projects built via a waterfall methodology is that they often become of laundry list of Must-Have's and Shall-Do's that become impenetrable to (an unread by) everyone except the person that wrote the requirements document. User Stories seem to help in offering clarity and context to a specific requirement, but how do you convey context for the gaggle of user stories that are part of an Epic? As a PM, the users of my product want to enjoy the benefits of the Epic, not an individual user story or the several, highest-prioritized user stories that can fit into an iteration or two.
In the past, I've taken the approach of crafting requirements documents that convey the benefits of the 'Epic' to a user or group of users that are presented using personas and mockups/wireframes. My goal has been to convey the context of the need and the overall spirit of the intended feature/enhancement. My developer partners in the past have expressed happiness in this approach of crafting requirements, but it is at odds with my new team in a new company that has already started to embrace Scrum. Any advice?
11 April 2008 07:01
Hi Ken
Personally, I couldn't agree with you more.
Writing personas/user roles for the different types of users, outlining the high level architecture, and some representative 'story boards' (wireframes/flat visuals) are all important ingredients before you get down to individual user stories on a large project.
On BAU (business-as-usual) products, you can of course forego this a bit more, because the context is provided by the existing product.
The important thing about the artefacts I've described above is that they remain high level, visual and negotiable. They are guides, not contracts or detailed specifications.
Kelly.