Skip to content

Breaking Down User Stories

iStock_000008002627XSmall

This post has been moved to my company blog at Growing Agile – you can read it here:

http://growingagile.co.za/2012/12/breaking-down-user-stories/

About these ads
11 Comments Post a comment
  1. All good advice. There is also the question of whether the architecture is too complex.

    October 27, 2010
  2. Great info here. Posted a VIA on our site! Thanks for the awesome work!

    December 20, 2010
  3. Hi Karen,

    Fantastic article on User Stories.

    The one thing I have been thinking about is a slight tweak to them based on the requirement of the Story.

    “As a I want” implies that it is additional functionality.

    Every system requires minimal functionality to exist, these need to be indicated.
    So what I suggest with our teams is this critical stories are worded differently:

    “As a I need” Implying that it has to exist,

    These generally form part of the absolute highest priorities for a minimal viable release.

    Keen to hear your thoughts :)

    May 30, 2011
    • Hi Nick
      I tend to think using need instead of want is a way of indicating priority. My preference is to have priority linked to each item in your backlog, but not necessarily in the wording of the story, because priority can change depending on business conditions. Rewriting stories every time business priorities change seems unnecessary to me.
      Also try to think of the “As a … I want… so that” just as a template to make sure you are considering all the important parts i.e. the role, functionality and value of each story. Once you get used to this you can probably phrase it in better english without using the format as strictly.

      May 31, 2011
  4. Mandy Schoeman #

    Hi Karen,

    Thanks for the great article.

    June 6, 2011
  5. Kevin #

    Hi Karen

    We tend to have issues around when to do architecture. Should we get all the user stories and then do a quick high level architecture for the system before going and doing story points or should we get the stories, do the story points and then do architecture only for what we are delivering? (I tend to feel its a good idea to have a kind of whole picture architecture before jumping in)

    What do you advise?

    November 19, 2012
    • I think it helps to have a high level idea of the architecture when you are discussing a story at the epic level. The key is the 80/20 rule. get 80% with 20% effort, i.e. don’t spend too much time on making it perfect, and maybe even have a few options for the architecture. As you flesh out the epic and add stories understand how those might fit into or change your architecture, this might also impact the order you do stories in. If something in the architecture is risky, you can influence the product owner to do a story that uses that part of the architecture first to find out if it works before you build everything.

      November 19, 2012

Trackbacks & Pingbacks

  1. Tweets that mention Breaking Down User Stories « Coaching teams to do better scrum -- Topsy.com
  2. Scrum Puzzle #5 | Coaching teams to do better scrum
  3. Lots of stuff about user stories, mostly how to write them and when to do architecture « ScrumMonster

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 46 other followers

%d bloggers like this: