Loading...
Latest news
How to Keep Your Product Strategy From Turning Into a Game of Jeopardy
The Maturity of your Market Dictates the Type of Product that You Need
Politics and your next release
What is a Successful Product? An Overview of Metrics and KPIs to Track Product Success
Product Management – You’re doing it wrong
Agile DevelopmentProduct Management

User Stories That Developers Can Actually Work With

raspler -

by Rivi Aspler

Devout Agile evangelists will define a user story as a short, simple description of a feature told from the perspective of the person who desires the new capability. The user story will typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>.

And furthermore, while a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of a user story (“As a user, I want…”) is incomplete until the discussions about that story occur and the discussions are those that actually enrich the user stories with enough details that R&D teams can chew on.

So much for theory and now for practice….

I have found that the concise user stories are simply not enough. It is especially apparent when one or more of the following occurs:

  • A – You are defining a new product, that doesn’t have enough legacy definitions, neither an established UI paradigm that the PO or the Agile team can rely on.
  • B – You are defining an utterly complicated product that requires an intensive analysis of hundreds of user stories, using multiple points of view (personas).
  • C – Your organizational culture is such that it encourages written down detailed specifications.

    • Since all of the above is my day-to-day reality, at my company, we are using the following guidelines for a user story template.

    Looking at the user story below, one can easily notice the following:
    1. We are using a table format.
    2. The left column of the table is dedicated to the ‘meta-data’ of the various definitions.
    3. Each user story has the same ‘meta-data’ topics listed down so that the PO and the developers can easily understand each-other.
    4. The user story defines a very granular scenario.
    5. The other user stories that complete the ‘Place an Order’ Theme are detailed in other user stories (i.e. the references to US19, US38 and US39)
    6. A UI design is attached since one picture is always better than a thousand words…

    [table id=4 /]

    To conclude, the above detailed template may not stick to pure Agile recommendations, but it does represent a win-win best practices for the type of definitions that developers practically need in order to get your story coded.

    Rivi

    Tweet this: User Stories that Developer can Actually Work With http://wp.me/pXBON-3ls #prodmgmt #agile