Welcome Changing Requirements, Even If You Don’t Want To

April 30, 2012

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Agile Manifesto, 2nd Principle

I have a confession to make: I find this particular principle hard to live up to. Let’s just face it: I don’t like surprises.

This week I’m going to try and live this principle. It turns out my kids are going to put this to the test almost immediately. We’re  getting ready for school this morning and the pre-schooler is off to a slow start. “Hey honey, can you take care of kid 2.0 while I take kid 1.0 to school?” Right off the bat I have a requirement that’s changed. Good grief!

Welcome changing requirements. So, I put on my patented Agile Smile and say, “Sure honey, no problem!”

The thing that makes last minute requirements changes tough is that you are usually so close to your goal when it happens. There I am: mentally I’ve got my coat on and one foot out the door headed to work (my goal). Here is a last minute request, a delay of game. A request for help. There is no question that I’m helping out my family by accepting this last minute request. However, it isn’t without some compromise (My own ability to get to the office in reasonable time). I think I’m juggling the needs of multiple customers in this case. Some days I do it well, other days…not so much.

One thought that occurs to me is that you have to have your customer clearly in mind (which I obviously don’t). Juggling multiple customers makes it really hard to manage changing requirements. It must suck to be product owner sometimes. The more I look at this principle, the more I want to re-write it:

“Welcome changing requirements, even if you don’t want to. Agile processes harness you to the customer’s every whim.”

And that’s probably a good thing. I think it’s going to be a long week…


Tom’s Catalog of User Story Smells

December 20, 2007

Here are a few smells I’ve encountered while working with user stories with different customers:

  1. One word stories
  2. Technical stories
  3. Stories missing goal
  4. Stories missing user role
  5. Stories specifying architecture
  6. Customer doesn’t understand stories
  7. Boring stories
  8. Too many stories

For each story there is a symptom and a related discussion of the problem:

One word stories

Symptom: Stories are just single words jotted on a card with no description or explanation associated with them.

Discussion: Although stories are “Intended to be a placeholder for a conversation” it is possible to stretch that notion too far. It’s easy to see how a product owner might think that they have a mutual understanding of the issue with the team – so much so, that they neglect to describe the story sufficiently. However, it’s critical that the story provide some simple context, some simple statement of action. A disciplined team sticks to the format: As a <user> I want to <do something> so that <I can accomplish goal>.

Single word stories can also be an indication that the team is writing the stories for the product owner.

Technical stories

Symptom: The story is written in completely technical terms that have no meaning for the customer or the business domain.

Discussion: This is probably the most common problem with user stories. Technical stories that refer to layers of architecture, or specific technologies are completely opaque to the customer. The customer finds it hard to understand the value of the activities if they are not written in business terms. If you go to a review meeting, ask the customer/PO to accept the story and they say, “I don’t know what that means.” Then you have a technical story.

Technical stories are also an indication of another smell: Customer won’t write and prioritize stories. As a result, the team ends up writing stories that make sense to them – technical stories.

Stories missing goal

Symptom: Stories contain user role and feature, but there is no explanation of why the user would want it.

Discussion: Incomplete stories of this type are quite common. The goal is what can provide context for the rest of the story. Often the goal is an expression of the value the feature has to the user. Often an inexperience product owner will neglect to put the goal in a user story.

Stories missing user role

Symptom: Story contains a description of the desired feature without a reference to the user role.

Discussion: Without knowing who the customer is, it makes it very difficult to understand the value a feature may have – furthermore, it’s almost impossible to assess the fitness of the feature to the user.

Stories specifying architecture

Symptom: The story contains references to architectural design or components.

Discussion: This is simply another version of a technical story. This comes up most often when there is a dedicated architecture team.

Customer doesn’t understand stories

Symptom: Customer/PO doesn’t recognize or understand stories

Discussion: It’s likely they didn’t participate in writing the stories.

Boring stories

Symptom: Stories sound stilted and without passion.

Discussion: This could just be that the stories aren’t well written and need to be refactored a bit. Another problem may be that the goal is not particularly compelling. Is this story prioritized correctly?

Too many stories

Symptom: The total number of stories in the product backlog has grown to literally 200, 300, 400 stories or more.

Discussion: This is waste. The team will very likely never get to those stories. When the backlog gets this large it’s time to prune it down to a more reasonable size.