16 Running with User Story Lite

In this chapter, we describe how Smith’s team started to apply user stories in their work. User stories have the benefit of getting the team to think, enquire and understand the value of what they do from the point of view of their users. The User Story practice is a popular practice, in particular for small teams. It originated from Extreme Programming (XP), a lightweight, efficient, low-risk way to develop software [16].  XP was in its turn inspired by Use Cases from 1992.  The User Story Lite practice is a simplified version of the User Story practice, created just for the readers of this book.

16.1 User Stories Explained

A user story [17] describes functionality in the system we are building that is valuable to a user of a system.  User stories are based on an approach that was proven successful back in the 1990’s and earlier, where, rather that write lengthy requirements documents, informal discussions were conducted between the user of the system and the developer.  A user story includes a written description that is used when discussing the story along with tests to help communicate what is needed to complete the story. By complete we mean everything that has been agreed upon that will achieve the user’s need. The idea of user stories is to provide a way to facilitate discussion to help clarify who (i.e. a role) a piece of functionality is for and how it benefits the role.  Recall that earlier in this part we explained that a role is a list of responsibilities that one or more members of the team accept.  A user story is often captured on a 5 x 3 index card with a very concise format or template as follows:

            As a < role, or type of user>, I want to <list here the function you want the system to do>, so that <list here the objective you want to achieve>

An example could be: “As a bank customer I want to have a direct deposit capability so that my employer can electronically send me my paycheck.” This template helps to ensure that the “Who”, “What” and “Why” are all considered and captured:

  • Who – will get the value?
  • What – do we need to achieve?
  • Why – are we doing it?

Note that this concept of role is different from the concept of roles we defined earlier in part 1.  The role of a bank customer is with respect to the system being developed, whereas roles such as Scrum Master and Product Owner are with respect to a software development endeavor. User story cards, of course, do not provide everything that a user needs.  They are placeholders used to remind the team of the need to conduct conversations with the users. The purpose of the conversation is to flesh out the details. These additional details can be added to the card, or they can be captured through additional stories. The primary value of user stories is that they get a conversation going between the development team and the user.

Figure 97       User Story Lite Practice Big Picture

Figure 97 shows the idea of applying user stories. A simple way of remembering what a User Story comprises:

  • Card – a succinct headline description, as captured on a Story Card
  • Conversation – the actual users of the proposed system and developers discuss what is needed to converge on the best solution
  • Confirmation – acceptance criteria, captured as bullet-point statements, which can be captured on the back of the Story Card.

To write a good user story it is useful to apply the INVEST criteria.  It is an acronym for

independent, negotiable, valuable, estimatable, small, and testable. Each of these six criteria items is discussed below:

  1. Independent - User stories should be independent of each other so they each can be developed separately. 
  2. Negotiable - At least part of the reason for promoting a conversation when using user stories is to support negotiation between the user and developers. To promote negotiation user stories should be written in a way that allows them to be negotiable.  Negotiation promotes understanding and commitment.
  3. Valuable - A user story should be valuable to the user.  The conversation can help team members understand the real intent of a requirement and the value each story brings to the user.  One way to help ensure each story has value to the user is to engage the user in actually writing the story. 
  4. Estimatable - A user story should be estimatable. As team members and users work together on user stories the goal is for enough details to emerge to allow the developer to estimate the work effort required to implement the story. 
  5. Small - User stories should be small.  Often when stories are first written they are too large to fit within a given iteration and therefore must be split into smaller stories. These large stories that are too large to fit within an iteration are often referred to as Epics. Through the conversations held between developers and users the needed smaller stories emerge and are agreed upon. 
  6. Testable - An important criterion to keep in mind for a good story is that when completed it be testable.  Writing the tests first help ensure the story is testable and helps ensure both the user and the developer are in agreement on what it means to complete the story. 

One question that often arises for beginners when using User Stories is:

But why do we need the “so that” clause in a user story?

One of the reasons the “so that” clause is added to the format of expressing a user story is so the developers understand the end objective of the user.  This helps to support evolutionary requirements development.  By evolutionary requirements development we mean that the requirements may evolve as we learn more about the available options and needs of the user.  This also keeps the developer’s options open in providing alternative solutions. Refer to Figure 98 and Table 9 for a summary of User Story Lite practice.

16.2 Making the User Story Lite Practice Explicit Using Essence

Just like what we did in the previous chapter on Scrum, we can be very explicit about how the User Story practice guides the team by understanding how user stories and various elements surrounding user stories are related. Figure 98 expresses the user story practice using the Essence language.

From Figure 98, it is clear that this practice is a way to decompose complex Requirements into sub-alphas - the User Story alpha. Each user story is described by a Story Card and is verified through a Test Case. The User Story Lite practice has several activities, namely:

  1. Find User Stories
  2. Prepare User Story
  3. Accept User Story

We will exemplify how Smith's team applies these activities shortly. Figure 98 also shows one pattern Splitting User Stories to help teams split user stories to ease development. Again, we will have further discussion shortly.

   

Figure 98       User Story Practice Expressed in the Essence Language

When you compare this with Scrum Lite in chapter 15, it is obvious that this User Story Lite practice is simpler than that of Scrum Lite.  Not only does User Story Lite have fewer elements than Scrum Lite, it also relates to fewer elements in the kernel, which in this case is only the Requirements alpha. Thus, a team applying a user story practice alone should consider other practices that provide explicit guidance on how to progress the other kernel alphas, such as Opportunity, Work, etc.

16.3 User Story Lite

In this section, we enumerate the elements of the User Story Lite practice in more detail.

Table 9           Elements of User Story Lite

Element

Type

Description

User Story

Alpha

Something that a software system could be extended to do, expressed in terms of the value that it will provide to a user of the system.

Story Card

Work Product

An index card, or equivalent, that captures the essential details of a user story.

Test Case

Work Product

Defines test inputs and expected results to evaluate whether a user story is fully and correctly implemented.

Find User Stories

Activity

Identify things of value that a software system could do. Capture these as simple and succinct headline descriptions on story cards.

Prepare a User Story

Activity

A user story is prepared for development by discussion with users to build understanding and refinement of its acceptance criteria and test cases.

Accept a User Story

Activity

The user story implementation is evolved in close collaboration with the customer/user until it is acceptable to and accepted by the customer/user representative.

Splitting User Stories

Pattern

Small things get done faster. In agile development there is a continuous and relentless drive to reduce the size of user stories by splitting bigger stories into smaller ones. The key is to ensure that each story delivers value:

* Splits should support meaningful user interactions, no matter how small or “specialized” (think “thin” end-to-end journey with each split providing value to the user.)

 

16.4 User Story Lite alphas

16.4.1 User Story

A user story is something that a software system could be extended to do expressed in terms of the value that it will provide to a user of the software system.

Figure 99       User Story alpha

A user story usually progresses through the following states:

  • Identified – The user story is identified with its value clearly expressed. It is placed in the team’s product backlog.
  • Ready for Development – The team discusses the details of the user story such that members are clear on what is involved in fulfilling the requirements behind the user story. This might involve details about user interfaces, implementation details, and so on.
  • In Progress – At this state, the team is working on fulfilling the user story.
  • Verified – The user story is verified by a qualified user representative, such as a member being the Product Owner, (i.e. Angela in this case).

16.5 User Story Lite work products

The work products in the User Story Life practice are the Story Card, and the Test Case for each User Story.

16.5.1 Story Card

A story card is an index card, or equivalent, that captures the essentials of a user story. It is normally expressed in “As a <role>, I want to <function>, so that <objective>” format.

Figure 100     Story Card work product

A user story can be expressed at different levels of detail:

  • Value Expressed – The value of the user story is clearly expressed, such as using the common format described above.
  • Acceptance Criteria Listed – The acceptance criteria for the fulfillment of the user story are clearly expressed.
  • Conversation Captured – The discussions the team has about the user story are captured so that the team understands more clearly the requirements for the user story and the rationale behind the details of the user story. These discussions are usually verbal, but can be written on the story card itself or some electronic means.

16.5.2 Test Case

A Test Case defines test inputs and expected results to evaluate whether a user story is fully and correctly implemented.

Figure 101     Test Case work product

A test case has several levels of detail:

  • Acceptance criteria captured – The different possible ways for testing the user story are captured.
  • Scripted – The step-by-step procedure for testing and accepting the user story is available. This necessitates also the preparation of test data and test environment used when executing the test case.
  • Automated – The test case is automated and can be executed with little or no intervention.

16.6 Kick Starting User Story Lite Usage

There were two primary challenges our development team faced that led them to decide to try User Stories Lite on their endeavor.  First, Smith’s team members sometimes found themselves wondering about the purpose of the system they were developing.    This often resulted in animated discussions with Angela. So, instead of just enumerating product backlog items, Angela recognized that by investing a little time in developing product backlog items in a user story form the resulting requirements would help the team better understand the purpose of the system they were developing. This would also help Angela when discussing the system with her stakeholders, such as Dave.

The second challenge the development team often faced was product backlog items being too large to fit within a single sprint/iteration. Smith had heard that the User Story Lite practice could help them with both of these challenges and so the team decided to try out this practice to see if it could help solve their challenges.

16.7 Working with User Story Practice

Working with user stories involves several activities (see Figure 102). First the team needs to find user stories, prepare each user story for development, and then accept the implementation of the user story. The implementation of the user story, (i.e. writing and testing code), is outside the scope of the User Story Lite practice we are describing in this section; it is expected to be addressed by another practice. Later in chapter 18, we will show how a microservice practice can be used to implement the user story.

Figure 102     User Story Lite activities

16.7.1 Find User Stories

Angela and the team were discussing which product backlog items they would target for the next iteration. Among them, are the following three backlog-items:

  1. Improve algorithms to rank destinations according to traveller specific preference
  2. Improve algorithms to rank destinations according to general popularity of destinations
  3. Collect user data from users and analyze them.

16.7.2 Prepare a User Story

Having agreed to the User Story Lite practice, the team proceeded to prepare each story for development in the next iteration. The preparation involved the discussion below.

Tom was quick to highlight that the purpose and scope of the above items were not clear.  For example, the team was not clear what the acceptance criteria for improving the algorithms were. They were also unclear what the purpose of collecting and analyzing user data was, and hence the scope of this backlog-item.

Smith explained the idea of user stories to Angela and she was quick to grasp the problem the team was facing and she understood how user stories could help. Together as a team, they expressed the user stories as shown in Figure 103.

Figure 103     User Story Examples

Tom, Joel and Grace were much happier with the user story form as depicted in the Figure 103 compared to what they had earlier (see part 2, section 11.1 through Requirement Items, and this part, section 15.4.1.2 with Product Backlog-Items) as this form helped them better understand the purpose of the system they were developing.  Furthermore, the added detail helped them estimate each story and ensure each story was small enough to fit in a iteration. 

Angela mentioned that expressing the requirements in a user story format demanded more effort from her, but after some discussion, she agreed that this small upfront investment was worthwhile because it made her think more about what she wanted. For example, in the first and second user stories starting from the left in Figure 103, because we now have agreed to acceptance criteria the team better understands what Angela will accept for improved algorithms.  In the third user story because it specifies “count clicks” and creates a “trend chart” the team understands better what Angela will accept for the data to be collected and how she expects it to be analyzed. The user stories would also help Angela when explaining to Dave, her boss, the specific requirements that the team would be focusing on in the next sprint.  Note that these were not the only three user stories they were delivering. There were others, but for brevity, we limit our discussion to these three.

The development of each story would involve designing user interfaces, writing code (User Interface code, back-end processing code and database code), preparing test data, testing the code according to the acceptance criteria. So, in general, completing one user story is not something each member could do in a day, especially if the user story involved new functionality, rather than a simple modification of some existing functionality. Keep in mind that explaining how the team conducts their implementation (code and testing) is outside the scope of our User Story Lite practice.

16.7.3 Applying the Splitting User Stories Pattern

As part of preparing user stories for development, the team proceeded to split each user story that was too large such that the outcome was smaller stories that are more aligned to the INVEST criteria (see section 16.1), especially the small and testable criteria. 

Figure 104     Splitting User Stories Pattern

Having smaller stories with clear test criteria makes each story easier to complete, which rewards team members with a sense of achievement and improves team member progress assessments.

As an example, Figure 105 shows how the first user story was split into 3 smaller ones.

Figure 105     Splitting a User Story

The team members took the guidance from the “Splitting User Stories” pattern for approaches to split user stories, ensuring that the smaller stories are testable all the time.

16.7.4 Accept a Story

The team worked on the user stories within the current iteration. They made it a point to have their acceptance criteria expressed clearly. This investment paid off as developers had a clearer idea what had to be done.  They found that it was not easy to specify acceptance criteria at the same time as they described the story, because they were not sure what was really needed. Nevertheless, they felt that doing their best to split the stories was the right thing to do. Over the course of the delivery of each user story, they regularly communicated with Angela and with each other regarding the details of the user story. The result was reduced disagreements when accepting the story.

Angela continued to work closely with the development team using their agreed to Scrum Lite practice. She also participated in the acceptance of each user story. Whenever issues arose during the sprint, she worked with the team to refine the acceptance criteria.

16.8 The Value of the Kernel to the User Story Practice

By describing the User Story practice in an essentialized form (i.e. activity cards showing relationships to alphas being progressed) the team could see which alphas were being progressed and where their requirements practice still had weaknesses. Specifically the team recognized that their User Story practice helped them achieve the following Essence kernel alpha states:

  • Requirements alpha: Bounded and Coherent state
  • Work alpha: Prepared state
  • Requirements alpha: Acceptable state

The explicit activities in the user story practice directly supported the team in achieving key checklists within the Requirements alpha: Bounded and Coherent states. For example, the User Story practice encouraged stakeholders and team members to discuss and to agree on the purpose of the new system, as well as helping everyone involved to achieve a shared understanding of the extent of the proposed system. Furthermore, discussions helped both the team members and stakeholders to work through issues related to potentially conflicting requirements (see checklist items in Figure 106)

Figure 106     Requirements Alpha: Bounded and Coherent state cards

Achieving the Work alpha: Prepared state was helped because the User Story practice encourage the splitting of each user story in order to break the requirements down into tasks that the team could estimate and commit to completing within a single sprint (see Figure 107).

Figure 107     Work alpha Prepared state card

The explicit activities in the User Story practice directly supported the team in achieving key checklists in the Requirements alpha: Acceptable state. For example, the User Story practice encouraged acceptance criteria to be agreed to which reminded the team of the importance of describing clear test steps that would lead to an acceptable solution (see highlighted checklist item in Figure 108).

Figure 108     Requirements alpha Acceptable state card

16.8.1 Visualizing the Impact of the User Story Practice

While the User Story Lite practice helped the team progress forward with multiple Essence kernel alphas, it did not solve all the challenges the development team faced with regard to satisfying Angela and progressing the Requirements and the Work alphas.   After some discussion, the team began to realize that the User Story Lite practice had a number of weaknesses that was holding back the team from fully achieving the Requirement Coherent and Acceptable states. For example, the informal nature of the user story format left too much room for ambiguity in the requirements, and the team realized they were having trouble seeing the “big picture” and how new requirements would fit in that big picture. This led the team to realize that they needed more help than the User Story Lite practice was providing when it came to structuring and documenting the stories within the overall system.   

Smith said that he had heard that the weaknesses the team had found in their use of the User Story Lite practice could be addressed if the team considered migrating to Use Cases. As a result, the team agreed to study the use-case practice, which we will present in the next chapter. 

The first thing they did is to compare the two practices and their coverage. We will present their comparison later once we have presented Use-Case Lite in the next chapter.  Here we will discuss the coverage provided by the User Story Lite practice.

Figure 109     User Story Lite coverage of kernel solution activity spaces.

The three activities in the User Story Lite only cover two activity spaces. In particular, there is no activity that covers the “Shape the System” activity space. This is the activity space that deals with the structure of the solution area including the structure of requirements, and the structure of the software system It is precisely, what Smith’s team indicated when they said they have trouble seeing the “big picture.” They had a list of user stories, but not how stories were related to one another. They could not see the shape of the software system. In the next chapter, we will present Use Cases as a way to deal with this gap.

We want to point out here again to make it clear to the reader that it is not our intent in this book to create arguments or explain why one practice may be better than another (e. g. use cases versus user stories). Our intent in this book is to help the reader understand the value of expressing practices in an essentialized form. Essentialization can aid teams in discussing their own endeavor situation leading to appropriate decisions.

By looking at their practices through the lens of Essence, the team was able to see the strengths of their current agreed to practices, as well as the weaknesses. For example, when the team was small and they had just a few requirements the user story format worked well for the team. But as their requirements grew and new team members were added they realized they needed a better approach to describe the big picture, and see how all the requirements fit in that big picture. By having an open and honest discussion about the weaknesses the team was able to agree on an improvement of migrating to use cases. In the next chapter, we will discuss what the team learned as they migrated to use cases and how it helped them with their current challenges.