PRINCE2 Agile 2016
Previous Section   Next Section

25.6 Agile concepts and techniques

25.6.1 User stories

User stories are a very popular technique used throughout agile. The thinking behind user stories is quite simple and if some basic guidelines are followed correctly their use can be quite effective. This simplicity only goes so far and user stories need to be complemented by a degree of rigour to gain the most benefit from this technique. The basics

The exact format can vary but will be based on describing ‘who, what and why?’ As a <role>, I want to <function>, so that <benefit>

Originally the above heading would have been physically written on a card or sticky note (see Figure 25.3 for an example of a well-written user story) but capturing this electronically (e.g. on a spreadsheet) now also takes place. However, there is more visibility and transparency if it is hand written (or printed off) and this is the preferred approach if possible.

Additional information is needed to evolve the user story – one important area being the addition of acceptance criteria (in the same way as with quality criteria for a PRINCE2 product description) in order to be able to test the user story. Sometimes this is called acceptance criteria or the definition of ‘done’. Further to this the user story should also contain at some point an idea of the effort involved in creating it and an idea of the value that it is worth to the customer. These two values could be relative or actual (see section 12.4.1).

PRINCE2 sees user stories as broadly similar to a requirement (which may be a product description or contained within a product description (see section 25.1.1 for information on how to map these terms). A user story does have its own style in that it is often low-tech (i.e. it is very simple in form) and is often a physical thing (such as an index card).

It is essential to avoid the common mistake made when using user stories, which is to see them for more than what they are. They are not fully or partially defined requirements: they are a starting point.

The purpose of a user story is to enable discussion and communication to take place in order to arrive at a thorough understanding of what the customer needs. The card provides interesting information but it is the conversation around it that is vital. Mike Cohn (verbal communication) describes it as ‘a token for a conversation’.

Further to this point it could be argued that the information on a user story is deliberately insufficient in order to necessitate a conversation with the customer. Further information

The ‘Three Cs’ technique (created by Ron Jeffries) distils this into three steps:

  • card writing the story card
  • conversation the ongoing discussion involving the card
  • confirmation writing the acceptance test.

The INVEST mnemonic (created by Bill Wake) is used by many as a simple checklist to create a well-written user story in that it should be:

  • I – independent
  • N – negotiable
  • V – valuable
  • E – estimable
  • S – small
  • T – testable.

In terms of managing the user stories (e.g. for planning purposes), making each user story ‘independent’ from one another means that someone can work on that user story without overlapping with or being dependent on someone else’s work. Making them ‘small’ further helps with planning and the quicker delivery of value.

‘Negotiable’ refers to the collaborative working between the customer and the team delivering the product.

The thinking behind making the user story ‘valuable’, ‘estimable’ and ‘testable’ focuses the customer and the team to be clear on what they are really trying to achieve. If these three cannot be achieved then there is more to do before work commences.

The SMART abbreviation can also be used in this way (i.e. Specific, Measurable, Agreed, Realistic, Timed). Epics

Embryonic customer requirements can initially be quite large or vague. This has given rise to a different type of user story known as an epic. In effect this is a high-level or ‘super-user’ story that will over time be broken down into user stories at a level of granularity that the delivery teams can work on. One approach to deriving the user stories is to walk through the process which relates to the epic.

Epics can appear on a product backlog but they would not appear towards the top, as they would not be written in sufficient detail. Hints that may prove useful

User stories should be seen as summarizing key information about a requirement. Therefore it would usually be the case that other supporting information or documentation would need to be referenced in order to fully understand all of the detail behind a user story. This supporting information could have many forms such as a more detailed written specification, figures and models or reference material such as standards and guidelines. These cross-references would be included as part of the user story.

People sometimes refer to epics as coarse-grained user stories that break down into fine-grained user stories.

If the user story clearly shows the information regarding effort and value, it can make prioritization easier. A high-value feature with a low amount of effort will stand out as a priority.

User stories evolve as understanding increases. This is why in an agile environment there is little desire to define them in detail in the early stages of a project.

Acceptance criteria are often harder to write than they may first appear. One approach is to frame the acceptance criteria in the form of user-focused questions. For example, if you are setting acceptance criteria for a coffee mug, the following may be appropriate:

Can I put boiling-hot water into the mug and drink from it within five minutes by holding the mug by the handle?

Just specifying the criterion that ‘it will need to hold boiling-hot water’ does not help with what the user actually wants to do (as the handle may be too hot to touch). Equally, specifying a thickness measurement in respect of the width of the mug (e.g. 2 mm) still does not relate directly to the user’s need. Creating user stories requires some skill

Creating user stories is often a lot harder than it appears. Creating good user stories and requirements are skills that can take a long time to master. Specialist roles such as requirements engineers and business analysts can add a lot of value in this area.

On projects that normally require more than one customer representative, the need for technical specialization in the area of writing user stories and requirements may become necessary.

It is one thing to write a user story, but another thing altogether to write a good one (see Figure 25.3).

Figure 25.3 A good user story and a poor one

Figure 25.3 A good user story and a poor one Definition of ‘ready’

Although not as common as using the definition of ‘done’ or using acceptance criteria, the use of the definition of ‘ready’ is a practice used by many in the agile community. This is, in effect, the opposite of ‘Are we done?’, as it means ‘Are we ready?’ For example, a definition of ‘ready’ could be created for a user story so that a delivery team knows that it can start working on it.

For example, in order for a user story (in this case prior to sizing/estimation) to be considered ‘ready’, it must:

  • contain all three fields describing the who, what and why
  • be understood by the delivery team
  • have a benefit that is measurable
  • have a function that does not contain a solution
  • adhere to the INVEST guidelines
  • have acceptance criteria that are understood by the team
  • define the user as a role
  • identify any supporting documents that are relevant. Technical stories

User stories, as the name implies, focus on the people and roles that interact with the product. This works well when we are describing what something does and what function it needs to perform. However, it does not work so well when we are describing how the product works in terms of such things as performance or speed. Further to this, when a customer is describing how the product needs to work, this often applies to many features. In other words this kind of requirement can cut across several user stories.

These kinds of requirements are often described as ‘non-functional’ and they need to be handled carefully when working in an agile environment. Fitting them into the standard user story format is possible (e.g. refer to the ‘user’ as ‘the system’) but treating them slightly differently and referring to them as technical stories is also an option.

An example of a technical story may be when work needs to be completed on the underlying quality of the product (often called refactoring in agile) or experiments and investigations need to take place (often called prototyping or spiking in agile). Sometimes this kind of story or requirement can be included in the definition of ‘done’, but these types of story are still important as normal user stories though they may be captured in a slightly different way. A means to an end

User stories are an effective technique when using agile. They are easy to manage, they stimulate collaboration and ultimately, when used correctly, improve communication. But always remember it is what happens around the user story that is far more important than the user story itself.

Previous Section   Next Section