Sebastian Durandeu Blog

  • Visitantes

Archive for the ‘SCRUM’ Category

Writing User Stories

Posted by sebastiandurandeu on March 26, 2010

El objetivo de este post es tener una referencia rápida de que cosas tener en cuenta para escribir User Stories (en inglés):

  • User Stories General Guidelines
    • Each story must be written in the language of the business, not in technical jargon. They should be comprehensible by both the developers as well as the customer team.
    • Each user story represents a discrete piece of functionality; that is, something a user would be likely to do in a single setting.
    • A user story is short and concrete, something like:

      ”A user can view detailed information about a company that has posted a job.”
      More details about the story can be written in the form of user acceptance tests, that is reminders of how to test a story, and attached to the story. For example:

    • Test with empty job description.
      Test with really long job description.

    • Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer team expected it to work.
    • To create good stories we focus on six attributes. A good story is (INVEST):
      • Independent
      • Negotiable
      • Valuable to users or customers
      • Estimatable
      • Small
      • Testable
    • Ideally, stories are independent from one another. This isn’t always possible but to the extent it is, stories should be written so that they can be developed in any order.
    • The details of a story are negotiated between the user and the developers.
    • Stories should be written so that their value to users or the customer is clear. The best way to achieve this is to have the customer write the stories.
    • Stories may be annotated with details, but too much detail obscures the meaning of the story and can give the impression that no conversation is necessary between the developers and the customer.
    • One of the best ways to annotate a story is to write test cases for the story.
    • If they are too big, compound and complex stories may be split into multiple smaller stories.
    • If they are too small, multiple tiny stories may be combined into one bigger story.
    • Stories need to be testable.
  • User Story Size
      1. Agile Theme. A set of user stories related.
      2. Agile Epic: Large user story. For a feature that you want eventually but that isn’t important right now, you can first write a large story (an epic). When you’re ready to add that story into the system you can refine it by ripping up the epic and replacing it with smaller stories that will be easier to work with.
      3. Agile User Story
      4. Agile Task
    • It’s good to have stories that can be coded and tested between half a day and perhaps two weeks by one or a pair of programmers.
    • User Stories categories by size:
  • User Story Roles
    • Each story should be written from a perspective of a user role. As part of the process of writing stories, you should identify all the user roles who will interact with the software.
    • A user role is a collection of defining attributes that characterize a population of users and their intended interactions with the system.
  • User Stories Estimations Techniques
    • Expert Opinion
    • Analogy
    • Disaggregation
    • Planning Poker: Mix of three. Based on the Delphi method.
  • User Stories Estimation Scales
    • Fibonacci (1,2,3,5 + 8 ) –> Story Point Estimation
    • Power of 2 (1,2,4 + 8 )
    • T-shirt Sizing –> For estimating Epics

Using Points makes the unit of estimation abstract, which makes it easier to commit to, and easier to adjust your commitments to. Points are an abstract number. They do not convert to a unit of time. They are simply a *relative* indication of size.

The non-linear sequence work well because they reflect the greater uncertainty associated with estimates for larger units of work.

  • Team Velocity
    • The amount of score completed by the team after one iteration.
    • The team’s first estimate of velocity will be wrong because there’s no way to know velocity in advance.

References:

Advertisements

Posted in Project Management, SCRUM | Leave a Comment »