User Stories / Story Points


User stories are one of the primary development artifacts for Scrum teams.  They are a short description of the feature as told from the perspective of the person (stakeholder) who desired some new capability from a current service, system or application.  Many Scrum teams have adopted the user story template developed by Mike Cohn, which identified who the end user is, what the end user wants and why in a single sentence.  This template is most often written like this:  "As a (type of user), I want (some goal) so that (some reason)."  Example: As an Incident Process Owner, I want to see a release of known errors in order to do appropriate service desk staff training. In this way team members are encouraged to think of their work from the perspective of who will use it, ensuring requirements get met and value is delivered. 

User stories are narrative texts that describe an interaction of the user and the service.  It focuses on the value that a user gains from utilizing the service.  A user story is a simile for the work being done.  They are often written on index cards or sticky notes and arranged on walls or tables to facilitate planning and discussion, the end result being collaboration and just in time definition over documentation.

A good user story uses the "INVEST" model:
  • Independent.  Reduced dependencies = easier to plan
  • Negotiable.  Details added via collaboration
  • Valuable.  Provides value to the customer
  • Estimable. Too big or too vague = not estimable
  • Small.  Can be done in less than a week by the team
  • Testable.  Good acceptance criteria

Story point is a subjective measure used by Scrum teams.  It is used to measure the work required to implement a story.  In simple terms it's a number that tells the team how hard the story is.  Hard could be related to complexity, unknowns and effort.  Teams can use a modified version of a Fibonacci sequence (https://www.mathsisfun.com/numbers/fibonacci-sequence.html) to help understand the amount of effort that any given story will entail.  Story points do not relate to hours, so if that will be a requirement (most of the time it is) then you shouldn't use story points within project management.

To gain knowledge and certifications in DevOps Foundation follow this link:  http://www.itsmacademy.com/dofnd/ 

Comments

Popular posts from this blog

The Role of Process Practitioner

The Difference between Change and Release Management

The ITIL Application Management Lifecycle and SDLC

Search This Blog