This chapter covers the following topics:

INTRODUCTION

Over the last decade the adoption of user stories as an approach to capturing requirements has increased considerably. So much so, that in some projects user stories have been used as the sole format for requirements. Using user stories alone carries risks, and different requirement formats should be considered for different types of requirements. In other words, projects should avoid a one-size-fits-all approach to eliciting, recording and analysing requirements.

While user stories are effective in capturing the essence of functional requirements, further techniques need to be employed to draw out the detail of the functionality or to provide a coherent view of the, often numerous, user stories.

This chapter discusses user stories and considers the alternative techniques that can be used alongside them.

MODELLING SYSTEM USAGE

Understanding the actors and roles, described in Chapter 11, for the solution under development is vital. Systems need to provide functionality that can enable users to perform the work required by the business. Making sure the right functionality is built is an essential aspect of agile software development, but needs business analysis input.

Outline functional requirements can be captured in many ways, but the best way to define the detail of the required functionality is to work iteratively so that the detail emerges over time. Where functionality is defined in detail early in the project life cycle, it often becomes out of date as the project progresses. This can lead to more time being spent changing and managing the requirements definitions rather than ensuring that the required functionality is delivered. Agile is clear that priority should be given to the delivery of working software rather than the maintenance of documentation, as it is the software that offers potential value to the organisation. An agile business analyst needs to ensure that ‘just enough’ detail is captured in the requirements documentation so that priorities can be allocated and decisions made about where analysis efforts should be deployed. Business analysts also need to work collaboratively with their customers to decompose requirements and goals such that priorities can be allocated at both goal and sub-goal levels. This helps the analysis and development work to move from an idea or concept, into something that can be realised in working software.

We have referenced the simplified Functional Model Map (FMM) throughout this book as it represents the required direction of travel from concept to solution. Figure 12.1 below shows the FMM as the analysis work begins to move from the solution to the internal components.

 

Figure 12.1 The simplified Functional Model Map

No two projects are the same and so it makes sense that the approach to capturing functionality may change from project to project. Having different formats available is an essential part of the business analyst toolkit and many have already been discussed in earlier chapters. Table 12.1 sets out different approaches and techniques for describing and capturing user stories that will be discussed in this chapter.

 

Table 12.1 Techniques for modelling stories and scenarios

User story	A short story describing a user role (who), what the user role wants to do and why they want to do it.
Scenario	A sequence of steps initiated by an event that will deliver an outcome.
BDD	A set of event-driven scenarios to be tested on the delivered system from the perspective of a user role.
Story map	A visualisation of the ideas and concepts for a solution (usually using user stories) to define what the solution needs to do, and the order in which it should be delivered.

USER STORIES

User stories were first developed with XP and were described as being ‘like use cases’. As time has gone on, the difference between user stories and use cases has become more apparent; however, both techniques are still relevant and useful, and can be used together on a project. User stories are small fragments of business value that can be delivered within a project iteration; this is usually a period of between two and four weeks. In contrast, use cases are project-wide goals that the solution needs to deliver and so will inevitably take longer than two to four weeks to deliver. The advantage of use cases is that they provide the wider context. The advantage of user stories is that the focus is on smaller goals, thus enabling small amounts of software functionality to be delivered within an iteration.

User stories, popularised by Mike Cohn in User stories applied (2004), seem to have become the de facto standard for requirements on agile projects. Each user story represents a slice of functionality that concerns the achievement of a business goal and can be divided up across iterations. Although a user story sets out a requirement, it does not represent a formal requirements document in the sense that a user story is not signed off and does not represent a formal contract between the customer and the development team. Rather, a user story is a placeholder for a further conversation that will help to elicit understanding and further details of the requirement.

User stories are often considered to have a hierarchy. This is not the same as the requirements hierarchy that has been traditionally assigned to requirements developed using a linear approach, whereby the high-level requirements break down into lower-level requirements and so forth, while traceability between them all is maintained and controlled. The terminology used to define user stories is considered more as a way of describing and managing the decomposition of user stories and is explored here in overview to help in understanding the level at which user stories should be defined. Further information on how stories can be managed and organised using this terminology is provided in Chapter 13.

During the initial development work user stories, which have been derived from use case models, will often be too large to deliver within a project iteration. Due to this they will need to be decomposed as described in Chapter 8. Managing user stories through decomposition has been the subject of much talk amongst business analysts and project teams. This has led to the development of a hierarchical structure for user stories that helps in their decomposition and allocation to iterations. The terminology used in agile to discuss the size and level of user stories consists of three main categories: themes, epics and user stories. These are described in Table 12.2 below.

 

Table 12.2 Levels in a user story hierarchy

Theme	The best way to think about a theme is as a logical heading given to a group of user stories. When user stories were captured on cards it made sense to put a rubber band around a collection of cards that were logically related. That way, if the functionality could wait until a later release, the cards could be kept together. Also, if the cards were dropped on the floor they would still remain in logical groupings. So, a theme is a heading given to a set of user stories that helps to organise them. The logical grouping could be based upon user roles (e.g. priority customer) or could be around features (e.g. online payments). Themes tend to be at an overview level and, in some situations, can represent high-level goals. Once a theme is decomposed, only the logical heading remains. Themes, therefore, should not be written as user stories; they are simply a heading under which user stories reside.
Epic	Epics are the name given to large user stories and are usually easy to identify as they are hard to estimate because of their size or they do not have a defined outcome or end point. An example epic from the training provider case study used throughout the book is ‘Manage course booking’. Epics need to be decomposed into smaller user stories as the time approaches when they will be used to develop software. In this sense, epics are transitory in that they only exist to be broken down. Jeff Patton (2014), in his book User story mapping, describes epics as resembling big rocks. Once a big rock has been broken down into smaller rocks, the big rock no longer exists. Instead, it is represented by lots of smaller rocks that if pieced back together make up the bigger rock. Similarly, once an epic has been decomposed into smaller stories, it no longer needs to exist. If there is an overwhelming urge to maintain the detail contained in the epic, then a theme should be used as a logical heading.
	It should be noted that the term ‘epic’ is sometimes used more widely to identify large pieces of work. For example, in Chapter 6 we refer to the ‘business epic’ as a container for work concepts that will require significant funding and consider all of the elements needed to deliver the business outcome using the POPITTM model. Epics are also referred to in SAFe (Scaled agile framework n.d.) for the enterprise, where they are described as ‘a significant initiative that helps guide the value stream towards the larger aim of the portfolio … they drive much of the economic value for the enterprise’. When discussing epics, it is helpful to clarify whether you are talking at a portfolio level or referring to a large user story in a development project.
User story	A user story is a description of desired functionality told from the perspective of a user or customer and which, once delivered, should provide value to the user or customer. User stories need to be small enough to be delivered within an iteration. User stories are the only category in this hierarchy that is realised by working software.

When writing user stories, there are six main attributes to consider in order to ensure that they are good stories. The suggested acronym is INVEST, which was devised by Bill Wake (2001) in his book Extreme programming explored. These attributes are:

Independent	Each story should be independent in that it should not be dependent on other stories. If it is not independent, problems can occur later when planning and estimating. Each user story should therefore represent a goal and offer value to the user.
Negotiable	The user stories should not be contracts or requirements that software must implement. They are short descriptions of functionality to be explored and negotiated in a conversation between the customer and development team.
Valuable	The user story should be valuable to an end user or customer. It must represent a goal or outcome of value that an end user or customer can understand. User stories that are only valued by the developers are not user stories. User stories should be written so that the user understands the consequences of not including them.
Estimatable	All stories must be given an estimate. If they cannot be estimated, they are either too big or the team lacks the technical or business knowledge to calculate the estimate.
Small	Each user story should be small enough such that an estimate to deliver the functionality can be calculated and the work may be planned. In the early days of a project, stories may be large and represent high-level goals for the solution. As the project progresses, stories should be decomposed so they are small enough to be delivered within an iteration (typically two to four weeks in duration).
Testable	Each story must be testable. It is this step that verifies that the working software is complete. The tests should be written from the user story confirmations and additional tests written that arise as the detail of the story is uncovered during the iteration. Within agile, as much testing as possible should be automated so that tests can be run again and again as the software develops through the iterations. BDD is used to identify the tests that can be automated.

Splitting and decomposing stories

Splitting stories can appear to be a simple process. In reality, it is a very difficult thing to get right as the stories need to be split and decomposed on the basis of achieving smaller goals and not sections of functionality. Goal decomposition was discussed in detail in Chapter 8.

The term ‘story’ is used in this book as a way of referring to the format (e.g. ‘As a … I want to … so that’), which is common for both a user story and an epic and is discussed further in this chapter. Where the author requires this to be specific, it will be made clear.

When splitting and decomposing stories there is a tendency to do this along technical lines. While this may make sense for the development team, it makes no sense to the customer as the story now describes technical functionality. Each piece of functionality could be developed across different iterations and therefore nothing of value can be demonstrated to the customer in an individual iteration. The value to the customer derives from the delivery of the whole story not the individual technical aspects of how it is built.

When splitting stories, Mike Cohn (2004) describes how big stories (i.e. epics) fall into one of two categories:

A compound story is an epic that has not yet been decomposed into user stories. For example, a web booking system may include the story, ‘As a customer I would like to book a flight.’ While this is fine during initial planning, when deciding what needs to be built, first further discussions with the customers may uncover that this story actually means:

Each of the above will become an independent story that can be prioritised differently.

Another way to split a compound story is to use the create, edit, delete framework such as:

The complex story is a large story that is harbouring uncertainty. In this situation, the team may need to spend some initial time understanding the problem in order to reduce the uncertainty. Once they are clearer about what needs to be done, further stories can be generated. An example of this may be the story ‘As a sales person I want the customer to receive discounts on their course price so that they can be rewarded for customer loyalty’ but the developers are unsure of how to implement this on the website as they do not know the rules associated with applying discounts. They may choose to split the story so that initially they include a story such as:

This story is a ‘spike’, which is a story that cannot be estimated without timeboxed research. This story, often referred to as a technical story, will be allocated to one or more of the development team to research during a timebox. If the uncertainty cannot be resolved within the timebox, the project will need to consider whether it is worthwhile continuing with this story. After completing this investigation, the original story can be further split into the following:

The patterns set out in Table 12.3 below provide useful approaches when splitting compound user stories. The examples given relate to the training company case study used throughout this book.

 

Table 12.3 Patterns for splitting compound user stories

Task steps
As a web maintainer, I want to post a new course description to the company website	• as a formatted pdf • as a reviewed Word document
Business rules
As a purchaser, I want to book course places	• on one course • across several courses • for multiple delegates
Simple or complex
As a reseller, I want to pay for a course place	• by credit card • by purchase order, invoice and remittance
Data sets
As a course delegate, I want to receive joining instructions	• in English • in Welsh • in French
Data/content entry
As a web controller, I want create news and events	• through links to other sites • by uploading formatted pdfs • by creating HTML pages
CRUD
As a purchaser, I want to	• create a course booking • change a course booking • cancel a course booking • check the course booking details

The 3Cs

When defining user stories, Ron Jefferies (2001) came up with the 3Cs to describe the three critical aspects of user stories: card, conversation, confirmation.

Card	User stories are written on cards or sticky notes. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement. It is used in planning. Notes are written on it, reflecting priority and cost. It is often handed to the developers when the story is scheduled to be delivered, and given back to the customer in the form of working software, when the story is complete.
Conversation	The requirement itself is communicated from customer to developers through conversation: an exchange of thoughts, opinions and feelings. This conversation takes place over time, particularly when the story is estimated (while planning for the release) and again at the iteration planning meeting when the story is scheduled for delivery. The conversation is largely verbal, but can be supplemented with documents. The best supplements are examples and are executable. These examples are called confirmations.
Confirmation	No matter how much discussion or how much documentation we produce, we cannot be as certain as we need to be about what is to be done. The third C in the user story’s key aspects adds the confirmation. This component is the acceptance test.

These 3Cs are discussed in detail below.

The user story card

The user story card is either a small card or sticky note used to capture the story itself. The card or sticky note is purposefully small in order to encourage the capture of the minimum detail. The user stories should be written by, or for, the project customers and should drive the development of the software. User stories should describe functionality that will be useful to a customer.

A typical user story format is as follows:

The ‘Who’ and ‘What’ are essential to the story, but the ‘Why’ only helps with clarity and determining the acceptance test. The ‘What’ is the actual goal of the user story. It is the thing of value that the role or actor wants to achieve. When splitting stories it is the ‘what’ that should be the focus of the goal decompostion. Stories help developers to ask relevant questions about the context and reason for the request, examining it from the perspective of the stated user role. Figure 12.2 contains an example of a user story for the course booking system.

 

Figure 12.2 Example user story

The conversation

The simple format of the story card aids communication between the various parties involved in the agile development work. Throughout the project, a series of conversations takes place between the customer and the development team and these conversations may be captured as additional documentation that will be attached to the card along with any discovered acceptance test criteria.

Although the card is a visible representation of a user story, the greatest value is derived from the conversations needed to develop the user stories from their inception to the delivery in working software.

A workshop is the primary method of obtaining user stories for agile teams and should be attended by the development team, a business or product owner, customers (including end users) and any other parties who can contribute to the story writing.

These workshops bring together all the stakeholders concerned with a particular system and should aim to achieve consensus and ownership with regard to the decisions that are made. Techniques, in particular brainwriting, described in Chapter 11, should be used to encourage the identification of innovative ideas during the workshop.

Cohn suggests the following format for story writing workshops as follows:

There are some important aspects to be considered when developing user stories, as discussed in Table 12.4 below.

 

Table 12.4 Guidelines for writing user stories

Write for one user role	Write stories from the perspective of one user, for example, as a registered customer (not all registered customers). Also, stand in the shoes of the user role and look at the system from the role’s viewpoint. For example, if I were a registered customer what would I want to do on the course booking website?
Ensure that user stories are valuable	Ensure that the user stories offer value to a user role rather than defining sub-goals or tasks that need to be undertaken during development. The user stories shown below are sub-goals, as logging on to the system and entering payment details are steps that the customer would need to complete in order to book a course. On their own they are not valuable to the customer as they define the user interface. • As a registered customer I need to log on to the course booking system. • As a registered user I need to enter my payment details criteria. This level of detail should not be captured as separate user stories. Instead the user story should read: • As a registered customer I need to book one training course for myself so that I can attend.
User stories have a meaningful end	Ensure that each story has a meaningful end. Consider the following user story: ‘As a registered customer I want to manage my bookings.’ How is it possible to know when a registered customer has finished managing course bookings? This would better be described as multiple stories such as: • As a registered customer I can view a course booking. • As a registered customer I can update a course booking. • As a registered customer I can cancel a course booking.

The workshop facilitator plays a key role in the user story workshop by keeping the workshop on track, applying the guidelines in Table 12.4 and ensuring that each participant contributes. Business analysts are often well placed to facilitate the workshop on behalf of the development team.

It is during the conversation that the detail of the story is revealed, so the user story itself is not a specification of what the solution needs to do. Therefore, user stories should not be ‘signed off’ nor should they form a contract for the software to be delivered. User stories should enable the development team to respond quickly, and with fewer overheads, to rapidly changing real-world requirements. The detailed requirement emerges as the user story is developed and the artefacts to define this detail may take many forms, for example, models, designs, business rules definitions and prototypes.

The confirmation

A user story remains an informal statement of the requirement until the corresponding acceptance test criteria are produced. Appropriate acceptance criteria must be written during conversations with the customer. These criteria will be used to ensure that the goals of the user story have been fulfilled in the resulting solution. The conversations uncover the detail of the requirement, which is developed within the working software and accepted once it is agreed that it delivers the confirmations agreed during the user story conversations. This is the main difference between a formal requirement, which forms a contract, and a user story, which provides a basis for collaboration. The intention of the user story is to be able to respond faster and with fewer overheads to rapidly changing real-world requirements.

The acceptance criteria for a user story are written as confirmations, usually on the back of the user story card as shown in Figure 12.3. It may be helpful to write confirmations for the large or high-level user stories described earlier (e.g. epics) as this helps to test business processes, and identify business rules or constraints. This can support the work to split the user stories and may provide a useful starting point for BDD scenarios (BDD is discussed later in this chapter).

When writing confirmations, it is useful to consider criteria such as SPAM:

S: security

P: performance

A: availability

M: monitor/measure

 

Figure 12.3 Example user story ‘confirmation’

Once a user story has been agreed for inclusion in an iteration backlog, formal acceptance tests must be written to ensure that the goals of the story are met.

For example, the user story ‘As a registered customer I want to cancel a course booking so that I don’t have to pay for a course I can’t attend’, may have the following confirmations:

A story can have any number of acceptance tests depending upon what is needed to ensure that the software functionality works correctly. A user story is not considered complete until it has passed its acceptance tests.

Where a user story is at an atomic level, in that it complies with ‘INVEST’ rules and is small enough to be delivered within an iteration, the acceptance tests should be written in a format compliant with testing. BDD is a popular approach for writing acceptance tests and is described later in this chapter.

Relevance of user stories

User stories are not appropriate for all types of requirements nor are they appropriate for all organisations, especially those who have a strong cultural bias towards formal sign-off of documents in order to release project funding. Other requirement formats exist for non-functional, general or technical requirements and these are discussed in Chapter 13. Adopting the user story format in a project, but then following stringent sign-off procedures for the stories in order to formalise a contract between the customer and the development team is not in line with the agile approach.

In his book User stories applied (2004) Cohn states that,

Agile is a philosophy underpinned by principles and values. User stories help in the application of the agile philosophy by providing a basis for collaborative discussions between developers and customers regarding the functionality to be delivered by working software.

SCENARIOS

Scenarios are used frequently in many aspects of business. They may be used to describe the different ways actors interact with a software system, a functional area of a business or the organisation itself.

There are many different definitions of scenarios, but in its simplest form a scenario describes a sequence of activities performed in response to a real-world event. The event could originate from outside the business or system, an external event, or could be an internal event originating from inside the business or system. Alternatively, an event could be based upon a particular date and time. Examples of events are:

In each of the above cases, the event would trigger a sequence of activities that would result in an outcome. The outcome is sometimes referred to as the scenario goal.

Scenarios are particularly useful as they help to uncover the detail of how work is carried out. This detail includes:

Scenarios help to identify where assumptions have been made and define necessary detail. They help to avoid issues such as business rules being misunderstood, data requirements not being identified or the wrong things being tested.

Additionally, scenarios enable ‘what if analysis’ to ascertain what would happen in a specific situation or if something unexpected happens. This is particularly important to elicit non-functional requirements or to derive tests to prove that a system or process is functioning correctly or within the limits expected. For example, what would happen if we raised 200 invoices concurrently; or if we expected to have a surge of users logging onto a system at the same time? The system needs to be tested to make sure it can cope with these possible situations.

Scenarios are developed using the approach shown in Figure 12.4.

 

Figure 12.4 Approach to developing scenarios

Scenarios can apply at various stages during system development and may be created using many different formats, both textual and diagrammatic; further information regarding documenting and modelling scenarios is presented in Chapter 11. Some of the typical formats used within agile approaches are described in Table 12.5.

 

Table 12.5 Scenario formats

Use cases	Originating from the UML, use cases describe the interaction of an actor with a system (both business or IT system). This technique is discussed in Chapter 11. Use case development begins by clarifying the basic flow or main usage scenario. Once this is understood, alternate flows are identified and documented. A use case may contain many flows. Each flow through a use case is a scenario.
Usage scenario	A derivative of use cases is defined in www.agilemodeling.com which uses specific examples of actors to represent the interaction and behaviour of that user in a given situation. This tends to make it more personal than the impersonal approach adopted for use cases. Other differences are that usage scenarios tend to follow just one path of logic rather than considering the basic and alternative paths defined within use cases. This is because usage scenarios tend to be developed ‘just in time’ and focus on a particular pathway that handles a specific combination of circumstances. They are usually discarded once they have served their purpose.
BDD scenario	BDD originated as a technique used in testing but has a lot of similarities to usage scenarios in that BDD scenarios are written from the perspective of a user with specific characteristics. BDD scenarios are defined for small individual user stories and represent the acceptance criteria for a story. BDD scenarios use a specific language called Gherkin and are defined below.

BEHAVIOUR DRIVEN DEVELOPMENT

Many agile projects are starting to adopt BDD as a technique for writing acceptance tests that can be automated. BDD is a collaborative exercise between the developer, tester and business representative, who is often the business analyst. It ensures that development projects remain focused on delivering what the business actually needs.

BDD was originally developed by Dan North (n.d.) in early to mid-2000. It addresses the problem that can occur when business analysts write a detailed specification that is then translated into software requirements by the developer and translated into test cases by the tester. This approach can lead to misunderstanding and miscommunication. BDD brings these roles together, as shown in Figure 12.5 below, so discussions are collaborative, thereby minimising the opportunity for miscommunication or misunderstanding. It should be noted that the roles may be perspectives that are adopted for the discussion rather than specific roles within the agile development team.

 

Figure 12.5 BDD collaboration

BDD can be very beneficial when used to develop acceptance tests in that it helps to ensure:

There are two main elements to BDD, which are:

Table 12.6 provides the structure used in BDD with a worked example.

 

Table 12.6 BDD structure and example

STORY MAPPING

Story mapping is a technique introduced by Jeff Patton (2014) to explore the broader picture for the system under development. This helps to provide a context that may be missing when using a backlog of stories. A story map can be used to visualise any backlog and therefore is not restricted to IT development projects. For example, it could be used with business epics (Chapter 6) to visualise process improvements. The story map provides several views of the system, including:

There are different approaches to creating story maps. One approach is to identify high-level user stories as a starting point. To create a story map, the following steps are suggested:

These steps are covered in more detail below.

Step 1: identify user roles and user stories

Before creating a story map, it is important to have done preliminary work to define the scope of the system and identify the user roles and user stories. A business process could also be helpful to provide a contextual view and determine the logical sequence of tasks. Both views are important to consider within the story map. It is worth sketching out existing business processes if they do not exist as these provide a better understanding of the ‘as is’ system.

Step 2: discover logical groupings

Analyse the user stories and group similar user stories under logical headings. For example, user stories such as ‘register bookings’, ‘cancel bookings or ‘update bookings’ may be logically grouped under a heading such as ‘manage bookings’. These logical headings are essentially ‘themes’ and will help to communicate the broader picture and help to order and prioritise the story map.

Step 3: place in a narrative flow (backbone)

The next step is to determine the narrative flow setting out the logical progression of the story map. This is sometimes called the ‘backbone’. Creating the backbone requires the themes (Jeff Patton (2014) refers to these as ‘activities’) to be arranged in a logical flow from left to right (horizontally) along a board or wall. The backbone must represent the flow of work of the business, reflecting the ‘tasks’ to be conducted and the order in which this should be done. For example, it is not possible to confirm a booking before the booking details have been received. Placing these in a logical flow helps the customer and the development team to visualise a workflow and identify any gaps.

Under each ‘theme’ place the epics (the high-level user stories), or tasks if using a business process model, for that theme. For example, if the theme is ‘manage payments’ then some of the epics might be ‘make payment’ or ‘process payment’. Figure 12.6 provides an example of a story map backbone showing themes and tasks/epics.

 

Figure 12.6 Story map backbone

Step 4: analyse for breaks in the workflow

The tasks in the story map backbone may be carried out by different roles and where this is the case it may be worthwhile showing the roles on the story map backbone. It is important to pay particular attention to points in the sequence where the themes transition to a different role, as this is where gaps may occur.

When using a business process model, it is worthwhile using it to validate the sequence of the themes and tasks on the story map backbone. Where there are differences between the story map and business process model views, there will need to be discussions about these differences to identify where changes need to be made. This may result in revisions to the business process model or may highlight missing aspects within the story map. This may result in the identification of additional epics and, ultimately, user roles and user stories.

This step helps to instil confidence in the story map, as it ensures that it is in a logical sequence that reflects the processes and working practices of the business.

Step 5: decompose stories

Once the story map backbone has been confirmed it can be populated with user stories. The user stories created during step 1 should be placed underneath the relevant themes and tasks defined within the story map backbone. When placing the user stories onto the backbone it is possible that a user story doesn’t fit under any of the themes or tasks currently identified within the backbone. In this situation, there are two possibilities: a new theme or task may need to be added to the backbone or the user story may be out of scope. This will require customer and product owner discussion to decide which is the case.

When placing the user stories onto the story map the level of criticality should be considered. This is represented on the vertical axis of the story map, which should be labelled ‘used frequently’ at the top and ‘seldom used’ at the bottom. An example of this is shown in Figure 12.7 below. User stories that are used more often should be placed higher up the story map than those seldom used.

 

Figure 12.7 Story map populated with decomposed stories

It is likely that the user stories identified so far are all epics and will therefore require further decomposition in order to uncover the lower-level user goals that can be delivered within an iteration. Decomposing stories was discussed earlier in this chapter.

Another technique for splitting stories is described by Jeff Patton (2014) and is called ‘Good, Better, Best’. This technique also helps to clarify the criticality of the story. The technique is concerned with asking the following questions, within each of the three categories, for each story.

Good

What would be just good enough for this story? For example, what would be enough to demonstrate the functionality but probably not enough to make a customer happy? Write down the characteristics that would make a story just good enough and then treat each characteristic as a separate user story. Place the new user on the story map according to the level of criticality.

Better

Then ask, what would make it better? This might include things such as speed of use, or improved navigation of screens or improved search ability.

Best

Finally ask, what would make it fabulous? This is where you can be really innovative. You don’t need to worry too much about feasibility or acceptability, as all stories are just ideas until they are agreed within an iteration.

Step 6: create a first release

Once the story map is created it can be used to decide what should be built first. Some teams focus straight away on the first iteration, where others focus on a first release that will contain numerous iterations. The first deliverable may be an experimental prototype that is demonstrated to customers in order to test an idea or reduce a recognised risk. This is often referred to as an MVP or Minimal Viable Solution (MVS). Feedback collected through the early deliverables will enable the customer and development team to learn from the process and create further user stories for future iterations and releases.

The early deliverables should facilitate and validate learning, so they may be low-fidelity prototypes that do not use or generate actual data. They may be prototypes that aim to address risk and test assumptions concerning functionality and usability, so they may not be appropriate for delivery into a live business environment.

Once ideas have been tested and risks reduced, future deliverables may focus on being complete enough for release to the live business environment. This is sometimes referred to as the MMP and should address the prioritised user needs and fulfil expectations of user experience.

Jeff Patton (2014) suggests drawing a horizontal line across the story map to identify the first deliverable. Everything above the line is in the first deliverable, and everything below the line will be done in subsequent deliveries as shown in Figure 12.8 below. Each deliverable, whether an MVP or MMP, should attempt to encompass the minimum set of stories required to meet the needs of the business. Patton’s technique of ‘Good, Better, Best’, combined with MoSCoW prioritisation (Chapter 9), may be used to define the minimum set of stories to be delivered. The earlier the deliverable is demonstrated, the quicker learning can take place. This will help to avoid wasting money and time – after all, initial ideas may turn out to be wrong!

 

Figure 12.8 Using the story map to define deliverables

Creating a solution with just the right amount of features sounds like common sense. After all, why would a project want to deliver more features than are necessary? However, determining the right amount of features can be difficult, so sometimes projects deliver over-engineered solutions that contain unnecessary features. Where this is the case, the additional features can clutter the user interface, making the system difficult to use, and can also increase maintenance cost. This is why the MMP is an important concept, as it helps the project team to focus on developing the features that matter to the customer.

CONCLUSION

This chapter has looked at a range of techniques that are relevant to agile projects, primarily where the focus is on software development but business application is also possible. Business analysts are well aware of the need to expand their toolkits in order to ensure that they can adapt to the range of situations possible on a change project. The techniques discussed in this chapter are beneficial in exploring requirements with customers such as end users and enabling the evolution of detail during the development process.

REFERENCES

Cohn, M. (2004) User stories applied. Boston, MA: Addison Wesley.

Jefferies, R.E. (2001) Essential XP: card, conversation, confirmation. Ron Jefferies. Available from: http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/ [20 December].

North, D. (n.d.) Introducing BDD. Dan North & Associates. Available from: https://dannorth.net/introducing-bdd/ [20 December 2016].

Patton, J. (2014) User story mapping. Sebastopol, PA: O’Reilly Media.

Scaled Agile Framework (n.d.) Available from: www.scaledagileframework.com [19 January 2017].

Wake, W.C. (2001) Extreme programming explored. Upper Saddle River, NJ: Addison Wesley.

FURTHER READING

Agile Alliance (n.d.) User Stories. Agile Alliance. Available from: www.Agilealliance.org/glossary/user-stories/ [20 December 2016].

Agile Inc. (n.d.) SAFe 4.0 for Lean Software and System Engineering. Agile Inc. Available from: www.scaledAgileframework.com [20 December 2016].

Ambler, S. (2002) Agile modeling: effective practices for eXtreme Programming and the unified process. New York: John Wiley & Sons.

Ambler, S. and Lines, M. (2012) Disciplined Agile delivery: a practitioner’s guide to Agile software in the enterprise. Upper Saddle River, NJ: IBM Press.

Bittner, K. and Spence, I. (2002) Use case modeling. Boston, MA: Addison Wesley.

Cadle, J. (ed.) (2014) Developing information systems. Swindon: BCS.

Cockburn, A. (2000) Writing effective use cases: the Agile software development series. Boston, MA: Addison Wesley.

Jacobson, E. (1995) The object advantage: business process reengineering with object technology. New York: Addison Wesley.