User Story Writing Starter Kit

Prior to Agile coming into existence, I was fortunate to learn how to write requirements by Elemer Magaziner (i.e., business requirements) and Alistair Cockburn (i.e., use cases).   They provided various alternatives to writing clear requirements that were irrespective of methodology.

 

From this I learned that there is a strong benefit to establish what I term as the “requirements language construct”.  This construct helps you consistently document your requirements focusing on key requirements elements. One common requirements language construct in the Agile world is the canonical form. It is important to realize that elements of the canonical form have been around for years.   With that being said, the three basic elements of the canonical form provide a good framework for establishing requirements. 

First I will discuss the user story that is typically expressed within the three-part canonical form.   Then I will introduce the enhancement of a requirements language construct that can adapt the canonical form.  The language construct for a user story in canonical form looks like this:

The persona is the user type who will receive the value.  The action is what the user type desires.  The business value is the benefit to that user type.  Note: you can learn more about personas in the article Personas – Do you really know your Users?   The following are examples of user stories in canonical form:

• As a learner (persona), I want to set up my profile to include my photo (action), so that my distributed team members know what I look like (business value).
• As a prospective buyer (persona), I want to search on homes (action) so that I know what properties are available in my price range (business value).

As enhancements to this construct, you may consider adding the system that will be used or interacted with and the receiving entity which identified the expected output from the requirements.  If applying these, the requirements language construct would look something like this:

As a (persona)

I want (action) from (system) to the (receiving entity) 

so that (business value)

The following are examples of user stories with these enhancements.  The first example below takes the second example from above and enhances it with the system and receiving entity.

• As a prospective buyer (persona), I want to search on homes (action) from MLS (system) to a separate window (receiving entity) so that I know what properties are available in my price range (business value).
• As a quant analyst (persona), I want a derivatives report (action) from the asset management application (system) in the form of a pdf (receiving entity), so that I can distribute it to my fund managers (business value).

There is no “right” requirements language construct.  It is important to craft one and then experiment with it.  I would suggest starting with the canonical form and work from there. 

Finally, the Product Owner, Business Analyst, Product Manager, and anyone who writes requirements should be trained in writing user stories in whatever form is used to articulate requirements. The Agile Team should be educated in understanding what to look for in a user story and asking questions regarding the elements of the canonical form. You may also want to train stakeholders and customers on how to provide their needs in your requirements language construct for consistency and clarity. 

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 18 of Being Agile. 

Applying the Agile Canonical Form to write Performance Goals

In most companies, employees have to do some level of performance management. This typically involves each person writing performance goals. For those of you in companies that are adopting Agile (or even if you are not), as you think about your performance goals, one of the things to consider is applying the Agile story writing canonical form as the approach to writing goal statements.

For those of you unfamiliar with the canonical form, it is a language construct that many in the Agile community use to document their requirements (aka, user stories). This includes the role (aka, persona or actor) you are playing, your action, and the business benefit.

In many cases, each of us has a primary role we play within an organization. However, we may also have secondary roles that we play. The canonical construct includes the role so the roles you are playing in your organization or your product team can be effectively added. This may help in describing your goal more effectively. For example:

• As a Scrum Team Member, I will size the work using story points with the team during Sprint Planning, so that we gain team buy-in for scope and size of the story

 • As a ScrumMaster, I will exemplify Servant Leader attributes (and not command-and-control attributes) in order to help my team become self-organized

 • As a Product Owner, I will continuously groom and prioritize the Product Backlog so that the Scrum Team has a solid list of stories in which to work through

 • As an Agile Coach, I will coach and mentor the product team so they can adopt effective Agile methods

 • As an Agile Educator, I will ensure effective Agile instructor-led training is occurring throughout the company

Once you have the performance goal written in this form, then you can list the tangible tasks that make up the goal underneath.  You may consider this another interesting way to use the canonical form (which is usually meant to describe User Stories within an Agile context) for other benefits.

In summary, it is a good idea within a performance goal to identify the role you will play in relation to that goal, what is the action you expect to complete, and why you plan to do that action (aka, business benefit).  Using the canonical form can be an effective way to articulate the performance goal. 

Holistic view of Continuous Integration & Build (Bite-size Stories) – Part 4 of 9

In the last episode (e.g., Part 3 of 9) of this series, I introduced the importance of the Agile and CM mindset.  One of the key elements in CIB involves an Agile and CM mindset change to think more continuously.  For Continuous Integration and Build to work effectively it is also important to ensure we are breaking down the work into bite-size stories and/or tasks to ensure we can have a potentially shippable increment.  Let’s examine this in more detail. 

In order to do continuous integration, you need to have the work broken-down into a size of work where you can integrate and build frequently.  The ability to specify the right ‘‘bite-size’’ level of story represents change that allow for granular and frequent code changes. This implies that the Agile team has the skills to understand the stories well enough in order to effectively break them down into small and consumable chunks.  This allows the team to make codes changes frequently and incrementally. 

But what are some techniques that help you break down work into bite-size stories? Here are a few ideas:

• Phrase your stories following the Canonical form.  A canonical form for a story is expressed as "As a I want to a so that ". This allows work to be segmented into actor, action, and benefit which helps in breaking down the work.

• Utilize the INVEST approach which stands for making a story Independent, Negotiable, Valuable, Estimable, Small, and Testable (established by Bill Wake). This approach helps us split larger stories or work into smaller bite-sized stories. Here are more details:

• I - Independent can stand on its own and could be demo’able
• N - Negotiable indicates that stories are negotiable and can be adjusted
• V- Valuable to the users and customer
• E- Estimable so that the stories can be sized
• S – Small enough to be bite-sized
• T – Testable so they can be verified and validated to work as written.

• Utilize the Use Case method that helps you break down work into functional steps. Each step should produce a piece of functionality. By using this approach, it provides you a basis for reviewing and determining the value of the functionality from each use case step in the flow. This then allows you to establish a more bite-sized approach to the work using a value and/or priority approach.

As you move to Continuous Integration and Build, your team must have the skills to chunk out the work into bite-sized pieces, in this case into stories that can be done within half the size of a sprint.  This makes continuous integration and build meaningful and allows for more frequent merging and building of the work.  Stay tuned for the next episode where we will focus on the Right-sizing your Branching and what this means in a Continuous Integration and Build process.

Note: If you started with this entry (Part 4), consider reading the first 3 earlier blog entries in this series.

• Holistic view of Continuous Integration & Build – Part 1 of 9
• Holistic view of Continuous Integration & Build (Elements of CIB) – Part 2 of 9
• Holistic view of Continuous Integration & Build (Agile and CM Mindset) – Part 3 of 9

Note: consider reading Adapting Configuration Management for Agile Teams, consider by Mario E. Moreira Wiley Publishing, 2010 for more information on this topic.