chris.hill

Getting Results from User Stories

User / Agile Stories, there seems to be no end to advice on how to write them, what template to use, what constitutes a story compared to a task, and similar writings on the topic (most of which are really helpful, provide a push in the right direction, and, at minimum, provide some good food for thought when creating your user stories). In generating stories I do find it helpful to have a template I like and structure to follow as those tools help provide the basis for what I truly care about from a story, an outcome.

When I’m writing a story I want that to transition from words to product and I find that there are a couple of different types of stories (regardless of template) that I end up writing. It is these differences that create the results and in actively choosing or writing specific stories, that helps both to create and set expectations on the delivery of that story.

The Four Types of Stories

  1. Story for Self aka Free Form: a story that will be self-consumed, i.e. the writer of the story will be the implementer of the story.
  2. Story for Outcome (w/o concern on implementation): a story where the outcome is the desire and how that outcome is achieved is not of concern.
  3. Story for Outcome (w/ concern on implementation): a story where the outcome is the desire, but also some aspects of the implementation are of concern.
  4. Story for Someone to Act as You: a story where the desire is for it to be as if you implemented, but for someone else to do the implementation.

Story for Self aka Free Form

In many instances the person writing the requirements or stories is one of the developers (or the only developer) and a story can take the form more of a note to oneself; or the story is so general that there isn’t a form to it:

  • Create user interfaces for score updates
  • Implement baseline graph of runs
  • Confirm usability of reporting components

This type of story is broad and generally under estimated (though if all the stories are like this, that will balance out); it is generally difficult for others (people that didn’t write the story) to pick-up or progress these stories without further communication. Sometimes these are proto-stories where the details are still to be determined; and if that work is or is not to be included in the story that can be appropriate.

Story for Outcome (w/o concern on implementation)

Depending on the type of development, who is impacted by different implementations, how long the product lifespan is, and a host of other factors; then the implementation isn’t as much of a concern as the outcome. If the user story isn’t concerned with a specific implementation (either back-end / technology or front-end / look and feel); but that the capability exists then these types of stories can provide.

The typical example is the “As a <user of type>, I want <outcome> because or to support <extra details>

  • As an administrator I want an interface to be able to update the scores of games with a minimum of effort and clicking to provide quick data entry
  • As an end-user I want to see a graph showing the number and speed of runs I’ve done for the month so I can compare and see the best results
  • As a developer I want to confirm that the reporting component selected will cater for the existing data reports (i.e. we can convert from existing to new component)

This can sometimes result in outcomes that are not in alignment with the story creators expectations (e.g. the score entry is a separate page rather than pop-up on the page) and/or the technology used might not be what is expected (the graph is being generated as a file, saved to disk and then shown to the client).

Story for Outcome (w/ concern on implementation)

This is a similar story structure as the prior item, but with a higher attention to detail as that is part of the expected outcome (i.e. the story creator doesn’t just want the short-term delivery of outcome, but rather either a cohesive delivery with other elements and/or an on-going structure to support)

  • As an administrator I want an interface, that is a single page, listing all the outstanding (i.e. game started, but score not finalised) games; to be able to update the scores of those games; and to do so with a minimum of effort and clicking to provide an ease of data entry
  • As an end-user I want to see a graph showing the number and speed of runs I’ve done for the month so I can compare and see the best results; this should be implemented using D3 and the aspects of the graph packaged into individual .js files for use in other aspects of the product
  • As a developer I want to confirm that the reporting component selected will cater for the existing data reports (i.e. we can convert from existing to new component) including extract to PDF and CSV capabilities; the component should work on both web and console based applications

These stories take a bit more time to define and involves thinking through some of the requirements / consequences; but if you have specific needs (i.e. it isn’t enough to have any user interface, rather you need one with touch-based scrolling) this can be very helpful to ensure you get the results you require. This also enables the clarification of important details (i.e. if something is important in the outcome it should be in the story definition).

These types of stories have the biggest tendency to be the garbage in, garbage out; though I don’t view them as that but rather “not defined in”, “unexpected out”. These stories also have a tendency to be the best estimated by story points as they are not so detailed as to sound easy; but have a clear expectations set out that enables users to think about effort to produce without glossing over details.

Story for Someone to Act as You

These stories are where you know exactly what you want but cannot implement (either don’t have the skills or time) but you want a very specific outcome.

  • As an administrator I want an interface, listing all the outstanding games; to be able to update the scores of those games; and to do so with a minimum of effort and clicking to provide an ease of data entry
    • The user interface should be a rows and columns structure with game Id, home team name and score, and away team name and score (no other data points)
    • On scroll the header row should remain visible
    • Outstanding Game is defined as where the start time of the game has passed, but the game has not been marked as completed
    • On save it should record the scores and mark any game with scores entered as completed
    • and so forth …

This one is obviously very time consuming, but it does guarantee both that you’ve thought out all of your requirements and that you get exactly what you are expecting. These stories are sometimes useful for new members of the team or people that are not familiar with the product itself and need more definition. It does limit creativity and alternative solutions to the issue to be solved.

Setting Your Expectations

In my experience a lot of frustration from the creation of a user story to the outcome of the user story stems from the creator thinking that the story falls into one category (i.e. thinking it will be an outcome with a specific implementation) but the story itself lending to another category (i.e. not nearly enough detail so the story ends up being a free form story)

Knowing the desired outcomes and the expectations of the team as to what is / is not assumed knowledge will help you to create better stories that help ease the team to meet the expectations you are (knowingly or unknowingly) setting for them.

References (How to Write Stories)

For those looking for resources on templates and some different ways to write stories, here are a few reference links as well:

Leave a comment