Traditional requirements approaches don’t work, but user stories are not enough.

So, what does work? Testable examples (i.e. ATDD and BDD) aka Specification By Example. Testable examples, sometimes called executable specifications, provide a lightweight, objective description of a need. They serve as a common language across roles, from business to the development team, allowing us to understand and improve our business rules. As an added benefit they can even be used to automate acceptance level testing.

So, don’t gamble on your requirements, review this introductory primer on ATDD and BDD.

I had the privilege of co-presenting this introductory with David Bulkin session in Las Vegas at the recent Scrum Gathering.

Be Sociable, Share!

• 

Attendees in Kitchener Waterloo – collaborating on building their Story Maps.

Story Mapping is a simple tool to help you visualize your Product Backlog. The traditional Product Backlog in Scrum is a real improvement over traditional methods for tracking and understanding the work ahead. However its still a long To Do List which has some issues:

• It’s hard to see the forest for the trees.
• It’s easy to miss important items in the morass of detail.
• It’s hard to prioritize well since we can’t see the big picture.
• It’s not explicitly focused on the user needs.

In other words, flat lists become confusing as the Product grows in size and complexity.

Story Mapping is a tool to help overcome these issues by helping the team visualize the needs of the end-users. Along the top we write out all the “User Needs”. On the Y-axis we create the Stories for each “Need” or task. Some “User Needs” aren’t of interest in the current release – so they might get no Stories. Other needs have a number of things that need to be done for them – so they get many Stories. In addition, each user gets their own map.

The key here is that the map acts as a tool to help organize the Stories. The map helps us spot gaps in our product and helps us discover the priorities. However, most importantly Story Maps help start conversations among team members about what we’re building.

The files below are from a series of Story Mapping workshops that I’ve facilitated in Montreal, Toronto and Kitchener-Waterloo this past year. If you would like to bring Mark into your company to facilitate a Story Mapping Workshop or teach a Product Owner course please email: courses@agilepainrelief.com

The files make the most sense if you’ve attended the workshop

• StoryMappingWalkThrough - the keynote presentation I run in the background.
• Story Mapping Basics - the basic introductory handout that all attendees get. It outlines some of the basic ideas behind Story Mapping and provides the core scenario for the exercises
• Julia Persona and Rob Persona - the personas that the audience gets to use for their exercises.

Be Sociable, Share!

• 

While working on the FedEx 2-day shipment story Martin discovers some very crufty code in the Foobar class. He doesn’t need to work in the class to complete the story, nor can he see it causing any bugs right now. He doesn’t want to ignore the issue so he grabs an index card and writes “Foobar class is very crufty and it will slow us down later”.

Later in the day the following conversation occurs:

Martin: “We need to rework the underpinnings of the Foobar class so that we can work faster.”
Product Owner Sue: “Martin, why is that important? Help me see that.”
Martin: “It’s slowing us down. Every time we work in Foobar we spend an extra 20 minutes just trying to understand the mess that is there. If you write a User Story and give us 5 days it will all be perfect.”
Jane: “Can I trust you? Will this be the last time I ever hear about the Foobar class? Where should I put this is in the Backlog?”
…
Read More…

Be Sociable, Share!

• 

Image Credit: robinsonma http://www.sxc.hu/photo/917101

The team has just completed Sprint Planning, committing to four stories:

• As a first time book buyer I would like to read a review so I can see if a book is worth reading.
  • A review has text and isn’t empty
  • A review has an author name
  • A review has a title
  • At most a review is 2500 characters long

• As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
  • Rating from 0 to 5
  • No ½ stars
  • Rating appears at the top of the review

Read More…

Be Sociable, Share!

• 

The recent Backlog Refinement session helped split the upcoming User Stories.

The team was able to get from a very large Story: “As a first time book buyer I want to read a trustworthy review before I buy a book” to:

• As a first time book buyer I would like to read a review so I can see if a book is worth reading.
• As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
• As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
• As a first time book buyer I would like to see reviews by friends highlighted so that I know whom to trust.
• As a staff member I would like to write a book review so that I can help customers choose great books.
• As a staff member I would like to rate a book I’ve reviewed so I can give customers a quick guide.

We’re in better shape than we have been with previous Sprint Planning meetings but the team lacks concrete acceptance criteria.

Analysis

During the first half of a Planning meeting the team is trying to determine its goal for the Sprint. Specifically, it’s trying to answer the question, “What stories can we commit to?”  To have a realistic commitment the team needs small Stories and a clear understanding of what they will look like when they’re done.

Story

Brad reads the first Story aloud, “As a first time book buyer I would like to read a review so I can see if a book is worth reading.” He sees an entire new web page, separate styling and a whole lot of infrastructure to support it. Doug, on the other hand, sees a small addition to each book page. He says that no new style sheets need to be developed. After a few more minutes of debate Product Owner Sue intervenes by saying that reviews will just live on the main page for now. In addition, each review must be under a thousand words and in plain text only. Read More…

Be Sociable, Share!

• 

Picking up from: Learning How to Estimate

The team are still in the Backlog Grooming/Refinement session. They’ve estimated a heap of stories and spotted several that need better Acceptance Criteria. However, there are several stories that Product Owner Sue would like to have worked on which are too large to commit to in a single Sprint. While they could estimate the Stories as they are this seems like a waste of time. They’re better off getting out the scalpel and splitting the stories into smaller parts.

First a quick reminder from – Why Split User Stories:

Read More…

Be Sociable, Share!

•