New User Stories Article on Agile Atlas

I recently co-authored a new article on User Stories with fellow Scrum Trainer Mark Levison. I think it’s one of the better introductory articles to User Stories on the net, and having the credibility of the Agile Atlas is great. Ron Jeffries, the co-inventor of User Stories, was one of the main reviewers of the article, so that was a little intimidating. But, he gave it high praise and only suggested a couple of minor edits. The article is now my “go-to” article on an introduction to User Stories.

Here is the article: http://agileatlas.org/gasps/article/user-stories

Other Good User Story Links:

• User Stories article on Agile Atlas (New! March 2013 – I co-wrote this one — great article if I do say so myself!)
• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• To see more information on grooming user stories, see:
  • What does Product Backlog Grooming Look Like?
  • Tips for Effective Backlog Grooming
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.
• I wrote a skit for a presentation I did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read the script of the skit here:
  • 

    Script_UserStoryUtopia.pdf

    • Download
• For good advice on how to split User Stories, see Richard Lawrence’s Story Splitting Flow Chart.
• For a good article on why to split User Stories, see Mark Levison’s Story Splitting, How Small is Enough?

I’m Giving a Free Global Webinar this Wednesday on “Acceptance and Story Testing Patterns”

I just wanted to send a quick note to my followers to let you know that I’m giving a free global webinar this Wednesday on “Acceptance and Story Testing Patterns.”

Here is the abstract for the presentation:

Acceptance Testing, also known as Story Testing, is vital to achieve the Agile vision of “working software over comprehensive documentation.” It’s very important that acceptance tests are easily automated, resulting in a phenomenon you may have heard of, called the “Agile Specification.” In this presentation, we’ll discuss eight different patterns of expressing acceptance tests so that they are easy to execute and automate. We’ll talk about popular patterns like Given/When/Then and Specification by Example, as well some other patterns you’ve probably never seen. Attendees will participate in an interactive exercise that will allow them to apply the most frequently used Acceptance Testing patterns.

You can sign up for the free webinar here:

http://tinyurl.com/d4d6ehw

Handling Non Functional Requirements in User Stories and Scrum

Handling non-functional requirements in User Stories can at first seem difficult, but as it turns out, there’s a pretty easy way to handle them.

For performance requirements and many other non functional requirements(NFR’s), one can use constraints and stories. What I usually coach is to create a story to document the NFR and define story tests for it. Then, I suggest adding the story tests as a “constraint.” A constraint is something that all implemented stories(features and functionality) must comply with. If you’re using Scrum, then you’ll want to add something like this to your Definition of Done(DoD): “All stories must comply with all of the story constraints.”

Example

Step 1: Identify and quantify the constraint and put it in terms that your users and business stakeholders will understand.

Story Title: System response time

• Story Test #1: Test that the system responds to all non search requests within 1 second of receiving the request
• Story Test #2: Test that the system responds to all search requests within 10 seconds of receiving the request

Some things to keep in mind:

• If you cannot quantify the story in concrete terms, this should be a bad smell that usually indicates a requirement that is too vague to be implemented. Vague NRF’s have the same problems that vague functional requirements do: It is hard to answer the question “How will I know when this story is correctly done?”
• Be sure not to specify a technical solution or implementation in the story, because stories are about “The What”(“What the user wants”) and they are not about “The How” (“How this is implemented”).
• Plan, estimate, split(if necessary), and implement this story like all other user stories, as part of the Product Backlog(Scrum).

Once this story is complete, the entire system will be in compliance with this particular constraint.

If your constraint is not system-wide or far reaching:

• Just add it as a story test for that story. But again, specify the requirement, not the implementation, in terms the business stakeholders will understand.

The decision to create a constraint or not will rest on whether the constraint should be taken into account in at least several future stories(or system wide). If it will apply to several future stories, then create a constraint. If it won’t apply to several future stories, then just add the NFR as a story test to the stories that it applies to, or create a separate story to comply with the NFR in the small part of the system that requires it.

Step 2: Add the Story Tests to your list of constraints (and to your Definition of Done if you’re doing Scrum)

Publish your list of constraints(and/or DoD) somewhere that is highly visible. Even if you keep your constraints electronically, print them out in large print and post them somewhere on your Scrum board or in your team area.

Constraints

Test that the system responds to all non search requests within 1 second of receiving the request.

Test that the system responds to all search requests within 10 seconds of receiving the request.

Test that the system logs a user out after 10 seconds of inactivity and redirects their browser to the home page.

Test that any update to a person’s payment information(anywhere in the system) is logged to the payment_preferences log, along with the following information: IP Address of logged in person Old preference value, new preference value Date/time of change

Test that any time a person’s credit card number is shown in the application, that only the last 4 digits display.

A note about Story size estimating:
Once a new constraint is added to the system, any stories in the product backlog that will have to comply with this constraint may need re-sizing if there is material time required to comply with the constraint. Said another way, all estimates for future stories will need to take into account the fact that the constraint must be complied with in order to call the story “done.”

If you’re doing Scrum, then add the constraints to your Definition of Done.

Definition of Done

All stories must comply with all of the story constraints<link to constraints page on wiki>.

All code must be peer reviewed within 4 hours of checkin.

If a change is made to the web services interface, the change must be documented on the official web services api wiki page<link to api on wiki>.

All code must have automated testing that is consistent with the “Automated Testing Guidelines”<link to guidelines on wiki>

Any change in of functionality that is visible in the GUI must be at least tested manually(automated tests also acceptable) against the integration environment before making the functionality available for a QA review.

Another note about Story size estimating:
Like I said above for the constraints, the Definition of Done should always be taken into account when sizing user stories. It might help to bring a copy of your DoD to your grooming and planning meetings to remind developers what all is included in their estimates.

Related Articles

• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• To see more information on grooming user stories, see:
  • What does Product Backlog Grooming Look Like?
  • Tips for Effective Backlog Grooming
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.
• I wrote a skit for a presentationI did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read download the script of the skit here.

A Visual Diagram of the User Story Life Cycle

This is a diagram I have created to illustrate a potential life cycle for a User Story, as well as how the Agile planning levels relate to the clarity of a User Story at different stages.

The italicized text attempts to answer the question “When does this phase typically happen?”

As in all things Agile, there is no one size fits all solution, so you’d need to tailor this to your organization and your team. My contention is that most User Stories go through all of the phases/levels whether you consciously realize it or not.

You can also download a PDF version of the diagram.

My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.

---

Scrum

1. The Scrum Guide (Must read for all)
   • http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf
2. Deemer, et al. “The Scrum Primer”
   • http://www.scrumprimer.com/
3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
   • http://www.amazon.com/Agile-Product-Management-Scrum-Addison-Wesley/dp/0321605780
5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
   • http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364
6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
   • http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
7. Derby/Larsen’s _Agile Retrospectives_
   • http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

---

XP (Extreme Programming)

1. Jeffries’ “What is Extreme Programming?”
   • http://xprogramming.com/book/whatisxp/
2. Jeffries’ _Extreme Programming Installed_
   • http://www.amazon.com/Extreme-Programming-Installed-Ron-Jeffries/dp/0201708426
3. Koskela’s _Test Driven…_
   • http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850
4. Martin’s _Clean Code_
   • http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
5. Feathers’ _Working Effectively With Legacy Code_
   • http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
6. “The Rules of Extreme Programming”
   • http://www.extremeprogramming.org/rules.html
7. Wiki entry on XP Practices
   • http://en.wikipedia.org/wiki/Extreme_programming_practices

---

Agile/XP Testing

1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
   • http://properosolutions.com/2011/10/the-secrets-of-successful-test-automation/
2. Cripin’s “Using the Agile Testing Quadrants”
   • http://lisacrispin.com/wordpress/2011/11/08/using-the-agile-testing-quadrants/
3. Crispin/Gregory’s _Agile Testing_
   • http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
4. Crispin/House’s _Testing Extreme Programming_
   • http://www.amazon.com/Testing-Extreme-Programming-Lisa-Crispin/dp/0321113551
5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
   • http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
6. Osherove’s _The Art of Unit Testing_
   • http://www.amazon.com/The-Art-Unit-Testing-Examples/dp/1933988274

---

User Stories (which originated in XP)

1. My “User Story Basics” article and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/User+Story+Basics
2. Cohn’s _User Stories Applied_
   • http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Lawrence’s “Patterns for Splitting User Stories”
   • http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

---

Special Agile Topics (if applicable)

1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
   • http://www.goodagile.com/distributedscrumprimer/
2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/The+role+of+Managers+in+Scrum
3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)
   • http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961

User Story Basics – What is a User Story?

What is a User Story? I’m glad you asked!

First of all, it’s important to say that User Stories are not a part of Scrum as defined in the required practices in the Scrum Guide. User Stories are but one way to represent Product Backlog Items in Scrum, and while it is the most popular method used, it is not the only method. Still, though, I would like to remind you that the User Stories practice is totally independent of Scrum, and thus it is not defined by Scrum. As such, everything else in this post is about the User Story practice and not Scrum itself.

Beware the common misconception!

There is a common misconception in the industry that a User Story is a sentence like:

• As a <user> I want <some functionality> so that <some benefit is realized>.

THIS IS NOT A USER STORY!!! This is the biggest User Story trap in existence! See Trap#1 and #8 of my article on User Story Traps.

What is a User Story?

<Definition>
A user story describes functionality of a system that will be valuable to a Non Development Team(NDT) stakeholder of a system or software. User stories are composed of three aspects:

• a written description or short title of the story used as a token for planning and as a reminder to have conversations
• conversations about the story that serve to flesh out the details of the story
• acceptance tests that convey and document details and that can be used to determine when a story is complete

</Definition>

What do they mean by Acceptance Tests?

Typically, in the context of a User Story definition, we mean tests that are represented by conversations, textual descriptions, tables, diagrams, automated tests, and so forth. When these Acceptance Tests are applied to the completed, implemented User Story, all of the tests should pass, and will thus prove that the story has been implemented correctly. If some functionality was not covered in a User Story acceptance test, then it wasn’t a requirement for that particular User Story.

Technically, in the context of a User Story definition, an acceptance test need not be automated or implemented. At the minimum, it should be described conceptually. The test should then be executed in order to prove the story and get acceptance, whether that be a manual or automated process. If your conceptual acceptance tests are described by one or more automated tests, then that is generally a much better practice, but not absolutely required.

Acceptance Tests should be automatable about 90+% of the time, though again, it is not required that they be automated. Having said all of that, when teams strive for development speed and quality, very few get far along that road without automating a large portion of their acceptance tests.

Acceptance Tests, in the context of User Stories, are also sometimes called Story Tests, Acceptance Criteria, Conditions of Satisfaction, and Test Confirmations.

Ron Jeffries, one of the co-inventors of User Stories and Extreme Programming (where the User Story practice comes from), has a good article that also describes User Stories in a basic way.

When do these Conversations and Acceptance Tests get created?

Typically, this happens in weekly Product Backlog grooming(also known as a Story Writing Workshop, Story Grooming, etc) sessions, but can also happen informally. The most effective backlog grooming includes some stakeholder/user representatives, the entire development team, and a Product Owner (Scrum) or Customer(XP). These sessions happen weekly and usually last 1-2 hours each. The goal of the sessions is to get stories that are “ready”, meaning the team has a shared understanding of the Acceptance Tests, and has the vast majority of the information they need to implement(code) the feature. See What does Product Backlog Grooming Look Like? for more on that topic. Keep in mind that sometimes a single User Story will be discussed in 2-3 grooming sessions before it is “ready”, especially if there are open questions or complex logic involved.

Frequently Asked Questions

Should I use a User Story to represent bugs/defects in a system?
The short answer is “it depends.” If it is a legacy or deferred bug, then yes, and it should end up on the Product Backlog(story points assigned). If it is a bug that was introduced since Scrum/Agile was put in place, then no, and it should end up on the Sprint Backlog(no story points assigned). See One way to handle Bugs and Production Support in Scrum for the longer answer.

Where do I get more info?

• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.

Story Testing Patterns – My Recent Presentation at Mile High Agile

You can now find my recent presentation(along with all the handouts, etc), “Story Testing Patterns” on my website here:

http://www.scrumcrazy.com/Presentation+-+Story+Testing+Patterns

Feel free to add any comments here on my blog.

.

A User Story Checklist

Sometimes it’s difficult to determine if something is a User Story or not.  Not everything a software team does is a User Story.

In my other article, User Story Basics , I talk about the definition of a User Story.  I will use that definition to make a checklist of characteristics a User Story must have.

1. Does the story describe new or changed functionality in the system under development?
2. Is the functionality primarily of value to a stakeholder playing a role other than the role of “developer on the development team for the system under development”?  Said another way, is the functionality primarily of value to a Non Development Team stakeholder?
3. Is there a fairly unique written description of the story?  (This can be just a couple of words, like a title)
4. Have conversations about the story, that clarify story details, taken place?
5. Does the story have acceptance tests that convey and confirm when the functionality of the story is complete, correct, and present in the system under development?

If you cannot answer “Definitely, yes!” to all of the above 5 questions, then it is almost always… NOT a User Story.

With respect to Question #2, I tend to define ¨developer” fairly broadly, like Scrum does.  From the Scrum Guide: “[Development] Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design…”.  On some development teams, people who play a role of developer also play a role of “product support member” for the system under development.  In this way, sometimes User Stories describe functionality that is important to someone doing production support.  Other than this one exception, though, functionality and features that are primarily of importance to developers are almost always not considered User Stories.  On the other hand, there is nothing wrong with a developer suggesting some functionality to a NDT Stakeholder, and/or convincing a NDT Stakeholder that some functionality will be primarily of value to that stakeholder.  If that stakeholder agrees, then you can re-classify that functionality as a User Story… so long as you can say “Yes” to all of the other questions above.

A question that often comes up is, “Should Fixing a bug be represented as a User Story?”  The answer is, it depends.  The only question we might have trouble answering “Yes” to is #2.  The first thing you should ask is this: What (already delivered) User Story Acceptance Test(or tests) fails due to this bug?  If you can’t point to one specific acceptance test, then it’s probably a missed acceptance test(meaning one was overlooked when the story was originally implemented) or a legacy bug(a bug introduced before you adopted User Stories), in which case, the bug should almost always be represented as a new User Story.

How I Classify My Coaching Advice

I often have a need to clarify my coaching advice so that teams understand how strongly or specifically I am targeting advice. Below is how I classify my advice, so the consumers of the advice understand how to apply the advice.

Advice Classifications

• Best Practice -a practice that is good in almost all contexts and almost all team situations.
• Worst Practice – a practice that is *bad* in almost all contexts and almost all team situations.
• Pattern(aka Good Practice) – a practice that is good in many contexts and team situations, but may not be good for all situations. As such, a pattern should suggest the context under which it is good.
• Anti-Pattern(aka Bad Practice) – a practice that is *bad* in many contexts and team situations, but may not be bad for all situations. As such, an anti-pattern should suggest the context under which it is bad.
• Bad Smell – strong evidence of a bad practice. While a bad smell does not always indicate a problem, it usually does.
• Tip – a practice that is definitely worth consideration, but might only be good in a few or very specific contexts or team situations.

My hope is that the consumers of my advice will know just how broadly, in my opinion, that the advice applies to problem spaces.

Scrum Guide 2011 – Backlog Grooming as a Required Practice

Intro

In my previous article, I give an overview of some of the interesting changes incorporated into the 2011 Scrum Guide. One of the most interesting changes in my view is the inclusion of Backlog Grooming as a required practice. In my Scrum coaching experiences, the one practice that seems to help beginner Scrum teams the most is backlog grooming. In some cases, the practice itself makes many PO related obstacles highly transparent, but transparency is what we want!

 

Backlog Grooming: The Red Headed Step-Practice.

I think that many beginner Scrum teams have trouble deciding on how best to transition to Scrum. They focus so much on the major practices (Product Backlog, Planning, Review, Retrospective), that they don’t realize that backlog grooming can ease some serious Sprint pain. This idea that the Sprint Planning Meeting is the first time we hear about all new backlog items is absolute nonsense, but that’s how the pre 2011 Scrum Guide read to a lot of people. Will there be late breaking backlog items that might be presented for the first time at the planning meeting? Yes, but it should be rare to very rare.

 

Third Time’s the charm…

I’ve found that most teams seem to have the highest productivity on implementing a backlog item when they’ve had a chance to discuss the item 3 times, with the 3rd time usually being the Sprint Planning Meeting for the Sprint in which it will be implemented. Each time a backlog item is discussed(with the whole Scrum team present), it is decomposed a little further and open questions and risks are identified. In between these three discussions, people should take action items to answer these questions and mitigate the risks. These action items are ones that often take days in duration to answer, for whatever reason (answers from stakeholders, technical deep thought and investigation, etc), but don’t take a lot of effort for each action item. Throwing all of these action items into a 2-4 week sprint means you’re putting these long duration tasks onto the critical path, and that’s just not productive.

 

My Coaching Style for New Teams

When I coach a team that is just beginning Scrum, I actually start with backlog grooming first. I usually pick a point on the horizon 2-3 weeks out and say: “Sprint 1 will start on date X, and between now and then, I want you to continue working how you have been working, except that we’ll have a few training sessions between now and Sprint 1 so that we can hit the ground running(or “Sprinting,” if you prefer). Much of the time in those training sessions is focused on good backlog grooming techniques (and usually User Stories and Story Testing). It all starts with requirements!

 

Experienced Scrum Teams are Not Immune

Other non beginner Scrum teams also never seem to get to the point where they do backlog grooming well. I think many Scrum teams plateau when it comes to implementing Scrum, and this is really unfortunate. As Jeff Sutherland suggests in the Enhanced Nokia Test (aka “The ScrumBut Test”), the huge productivity gains for Scrum teams are in the last mile of implementing Scrum. If a team never gets to that last mile, then the high productivity promised by Scrum is never achieved. If your team wants to get highly productive, then your team needs to get really good at backlog grooming.

 

In My Ideal World…

In my ideal world, a team will first see a backlog item at a high level in a Release or other high level planning meeting. They will then dive deep into the item during a backlog grooming session near the beginning of the Sprint before its most likely implementation, identifying requirement and technical risks, logic questions, and other things that get in the way of fully decomposing the item into acceptance (or story) tests. Then, the item might be lightly touched on outside the grooming when unknowns become known, or maybe again in a grooming session a few days before the next Sprint. Then, at the Sprint Planning meeting, there are only very minor unknowns about the item, and the team is well versed on what is trying to be accomplished by the item. Knowing what work will need to be done for the item means the team can better plan their work for the Sprint. They can front load risks, parallelize efforts (automating the acceptance tests is a good parallel effort), and visualize the critical path for this and other items.

 

Where to Find Out More

I’ve written a series of articles on Backlog Grooming. <shameless plug> I haven’t updated them for the 2011 Scrum Guide yet, but nothing much about the 2011 Scrum Guide changed the practice itself, so probably 97+% of the material is still applicable.

 

For my articles on Backlog Grooming, see:

• Why do Product Backlog Grooming?
• What does Product Backlog Grooming Look Like?
• Tips for Effective Backlog Grooming