New and Improved User Story Lifeycle Diagram — Free Creative Commons PDF download!

I had a designer friend update my User Story Lifecycle diagram, and she did a fantastic job!  You can download the PDF here:  http://www.scrumcrazy.com/lifecycle

New and Improved Diagram:

UserStoryLifeCycle_final_lg

The Older Diagram(also still available at the above link):

UserStoryLifecyclexm

Other Good User Story Links

Bradley Bug Chart Referenced in Awesome New Scrum Book

The Bradley Bug Chart was referenced in an awesome new Scrum Book that is now on the market.

Background

I got an email from this guy named Rich one day who wanted to talk by phone and ask me some questions about the Bradley Bug Chart. A great collaboration ensued, and I incorporated some of his suggestions into my chart. A couple of weeks later, he asked me to review Chapter 1 of this book he was writing. I have some of the highest standards around, and I’m not easily impressed, but that first chapter was extraordinary! Through that one chapter, and the conversations with Rich, I realized this guy knew Scrum inside and out. I then reviewed and commented on a few more chapters. I get asked to do unpaid reviews often, but I only spend my time on things that I think are excellent for the Agile community. I’ve spent some time reviewing another book that hasn’t been published yet, and it too, is a great one for the industry in my opinion. More on that one when it gets published.

The Bradley Bug Chart Gets Called Out

A little while later, Rich asked me if he could refer to my Bradley Bug Chart in his book(see page 277), in a section on how to handle bugs in Scrum. I was ecstatic, in part just having my work get recognition, but it was also recognition from someone I highly respected myself. It was great. I also re-wrote some of the praise that I gave Rich on that Chapter 1 review as a quote for his book. Rich also ended up quoting me a few times in other parts of the book, particularly in the chapter on “Continuous Improvement.” I’m not trying to brag here, just sharing the satisfaction of seeing some of my hard work and learning as being objectively recognized in the community.

About the Book

Here is the quote I wrote for his book:

  • “Finally a book about Scrum from the Development Team’s point of view. Richard’s description of the best and worst ways to implement Scrum is priceless. The first chapter alone is one of the best descriptions of ‘Scrum done well’ that I’ve ever seen.” — Charles Bradley

I highly recommend his book for anyone working with Scrum and Microsoft Visual Studio/.Net technologies.

Here is the book:

PSDBook_Small

Small Caveat: Rich is and was a trainer with Scrum.org, and since our initial collaboration, Rich inspired me to become a trainer for Scrum.org as well. So, while none of this was true at the time of the above events, I wanted to mention that we are now both trainers for Scrum.org. I have no financial interests in his book, whatsoever, and my journey to become a Scrum.org trainer came after my review of his book. Thanks Rich!

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:

Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

ScrumCrazy.com update:

  • Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
  • Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!

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

Towards a Catalog of Scrum Patterns

I’ve been thinking a lot lately about Scrum patterns.  To that end, I’ve drafted a conceptual model, which is depicted in the below image.  (You may want to click the image twice to see a bigger view of it)

ScrumPatternsOverviewOnePage

“Sprint Progress Monitor” is my term for what used to be called the “Sprint Burndown.”  In the 2011 Scrum Guide, Sprint Burndowns were no longer required but some way of monitoring sprint progress, via summing the remaining work, was still required.  In the Scrum Guide, it is made clear that these practices can be implemented using several techniques, and “techniques may vary” from team to team.  So, this is what inspired me to use the term “Scrum Technique Pattern.”  A Scrum Technique Pattern(STP for short) implements the intentional gaps left by the Scrum Guide.  Teams can inspect and adapt their technique patterns, while still fulfilling the Scrum framework.  Said another way, there are intentional “variation points” in Scrum, and the STP’s are different ways of implementing those variation points.

“Optional Scrum Patterns” are patterns that can be used in conjunction with Scrum, but are not specific implementations of Scrum techniques as specified or required in the Scrum Guide.  These can be just about anything, but they must follow and/or support Scrum principles in order to be considered as an Optional Scrum Pattern.

I also see the need for the ability to create a “mashup” of different Scrum patterns to create a set of practices and techniques for a particular team or context.  For instance, we might start out with a Scrum Starter Kit that includes things like:

  • Holding a Release Planning meeting every 2-3 months (OSP)
  • 2 Week Sprints (STP)
  • Using Story Points to estimate Product Backlog Items(STP)
  • Using Ideal Hours to estimate Sprint Backlog plan items(STP)
  • Doing a typical burndown chart to sum the remaining work for the sprint(STP)
  • Representing Undone Work(OSP)
  • Doing the typical “round robin” style of the Daily Scrum(STP)
  • Doing a fairly typical “Plus-Delta” retrospective analysis(STP)

Any of the above patterns could be interchanged with other patterns, and the Scrum implementation would still conform to doing correct Scrum.  Presumably the change to different patterns would be an attempt to improve a team’s ability to delight their customers and users.

Who writes these patterns?  Where do they come from?

In a word, anywhere.  I’ve seen dozens of them on the internet and in books.  I’ve documented a few original ones myself(though many of mine are adapted from others, and I would make every reasonable attempt to give credit where credit is due).  I would not be attempting to create all of these patterns, but to assemble them and label them so Scrum practitioners can easily understand which of them are optional, and which are fulfilling required practices of Scrum.  Of course, it will also become helpful to understand where these patterns fit into the grand scheme of Scrum, and I have some ideas along those lines, too.

I will keep iterating on this concept, and I hope to get back to you with more on this topic in the future.

Agile2012 Q&A – Ron Jeffries and Chet Hendrickson on Simplicity

I had the good fortune of being in a Q&A Session at Agile2012 with Ron Jeffries and Chet Hendrickson, early pioneers of Extreme Programming(XP), and both now Certified Scrum Trainers. Ron and Chet were sitting on the “expert couch” taking questions from the audience. I decided to break the ice by going on stage (questioners had to sit in the “therapy” chair next to the couch, and were time-boxed to 10 minutes) and asking them the first question of the Q&A session.

Keep in mind that this is just my recollection of the event. I’ll encourage anyone present to correct or add to what was said from their recollection. I lobbed them a softball of sorts. It wasn’t a hard question, but I wanted to hear their answer as Agile Manifesto authors. A friend in the biz had recently asked this question of me:

How do you interpret this Agile Manifesto principle?

  • “Simplicity–the art of maximizing the amount of work not done–is essential.”

I asked Ron and Chet to give some background on what that principle was meant to convey. Ron spoke from a programming perspective mostly. He said that simplicity refers to Kent Beck’s 4 rules of simple design. Kent’s definition stresses:

“…In priority order, the code must:

  1. Run all the tests
  2. Contain no duplicate code
  3. Express all the ideas the author wants to express
  4. Minimize classes and methods…”

The above is copied from Ron’s article on Emergent Design. Ron added that simpler is often simpler than you think, and simpler is often smaller than you think. He mentioned the phrase “the simplest thing that could possibly work” as a reminder to keep design and code simple.

Chet then chimed in on the topic of slicing stories smaller. By slicing them smaller, we can de-prioritize smaller stories in a more surgical way, thus avoiding work that is not needed right now, and may be never needed. There are also other huge benefits to smaller stories in that they are easily digestible, and thus less work to understand and implement. Chet stressed that smaller is probably smaller than you think. I then chimed in and mentioned a concept I had read in one of the XP books. If all of the details of your user story won’t fit on a card, then you should use a *smaller* card so that your stories are sized smaller because you’re clearly making stories too large and probably need practice at making them smaller. Chet finished by mentioning that, while simple is simpler and smaller than you think, you should be constantly inspecting and adapting your “simplicity” optimum.

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 Visual Diagram of the User Story Life Cycle

This blog post is now deprecated.  Please see the new updated blog post:

https://scrumcrazy.wordpress.com/2013/06/13/new-and-improved-user-story-lifeycle-diagram-free-creative-commons-pdf-download/

 

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)
  2. Deemer, et al. “The Scrum Primer”
  3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
  4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
  5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
  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)
  7. Derby/Larsen’s _Agile Retrospectives_

XP (Extreme Programming)

  1. Jeffries’ “What is Extreme Programming?”
  2. Jeffries’ _Extreme Programming Installed_
  3. Koskela’s _Test Driven…_
  4. Martin’s _Clean Code_
  5. Feathers’ _Working Effectively With Legacy Code_
  6. “The Rules of Extreme Programming”
  7. Wiki entry on XP Practices

Agile/XP Testing

  1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
  2. Cripin’s “Using the Agile Testing Quadrants”
  3. Crispin/Gregory’s _Agile Testing_
  4. Crispin/House’s _Testing Extreme Programming_
  5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
  6. Osherove’s _The Art of Unit Testing_

User Stories (which originated in XP)

  1. My “User Story Basics” article and all of the links at the bottom of that article
  2. Cohn’s _User Stories Applied_
  3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
  4. Lawrence’s “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)
  2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
  3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)
Follow

Get every new post delivered to your Inbox.

Join 255 other followers

%d bloggers like this: