Advertisements
Posted by: jsonmez | March 2, 2010

How to Hang a Picture: Agile User Stories

How many times do we complete a backlog item or user story and end up with something like this?

Holes in the wall from where we changed the requirements 10 times during the sprint; picture is crooked because that is what the final requirement said; picture is not centered on the wall because we already put too many holes in the sheet rock there.

Let’s be honest here.  If you hired someone to come to your house to hang a picture on your wall, and he ended up doing a job like the one above, you wouldn’t think it’s your fault.  Neither do your users or your business people.  They look for the guy with the cheesy grin holding the hammer.

From his perspective it makes sense.  Before he even looked at your wall, he asked you to draw a picture of your living room.  He asked you to give him the exact dimensions of the picture you wanted to be hung.  He even asked you for the exact height and horizontal distance to hang the picture.  You couldn’t provide him with any of those things, so instead you gave him the best description of your living room, the size of the painting and where to hang it.  With that he did the best he could and hung the painting on the wall.  You didn’t hear from him again until he was “done.”  (Some strange person from his company even came by and did a bunch of measurements with a tape measure, checked the strength of the nail and a bunch of other tests, and finally also stated it was done.)

You take a look at the work.  Nicely anchored to the wall, as level as possible, exactly in the wrong place.  You quibble over the work for a bit.  He pulls out his tape recorder and plays back your exact description of the site and how you wanted the picture hung.  As he plays it back he points out how he did exactly what you asked.  And he is right, sort of.  What he did matches what you said, the only problem is what you said could be interpreted several ways.  The way he interpreted it wasn’t what you intended; he should have asked more questions.  As you look at the placement of the painting, you realize the original height, which he actually did get right, is not what you want anymore, now that you can see the painting on the wall.

You try again, trying to be more specific with your requirements this time.  He asks a lot more questions, you have a hard time answering without seeing the project.  Finally, after some time you agree on how it should be done, and he sets out to tear down the old painting and re-hang it again.  You don’t hear from him again until it is “done.”  The process repeats, more holes in the wall, more playing back your words.  He’s honestly trying to do a good job, you’re honestly trying to tell him what you think you want, but it is hard upfront.

Finally, you end up with the picture above.  Lots of holes in your wall and a crooked painting hung in the wrong place.  It is not what you wanted, but rather than go through this process again, you decide you can “just make it work.”

Can you see the problem yet?

If you’re exclusively blaming either party here, you’re not looking hard enough.

The problem is, you would never hang a painting like this.  If you were going to hire someone to hang a painting, you would stand there in the living room while they held the painting at various levels and locations against the wall.  Someone listening nearby might hear:

“Higher, higher… ok now stop.  Wait back lower again.  How about a little to the left?  Hmm, I don’t think it is quite straight.  Ok, now it is.  Yeah that looks good.  Honey what do you think?”

What about you?

So, how are you developing your backlog items or user stories?  Are you doing them like the first example, where you are asking for all the requirements upfront and then building what you think the business person wanted?  Or, are you doing like the second example where you are working with the customer as you build the solution, not putting nails in the wall until you know you have built what the user wanted?

As developers, especially if we have come from a waterfall background, we have the tendency to want to get all the requirements upfront.  It is often difficult to figure out how to work with the customer to build the solution instead of simply gathering the requirements and then doing the work.  There may also be barriers in your organization which prevent you from doing so.

Here are some tips to help get the customer involved:

  • Co-locate.  The best way to communicate is face to face.  If you have to email, message, or call your business person or customer, you are adding overhead which makes it less likely to happen and more difficult.
  • Keep the story about the business problem, not about the solution.  This will force you to talk to the customer about the solution later.
  • Don’t try to do one upfront design for the story.  Instead have mini-design sessions as you go.
  • As soon as you have something to show to the customer, show it to the customer, even if it is on your own development work-station, even if it is a picture you drew with a marker.
  • Have the customer develop or co-develop the test cases with the team or person doing the testing.  Developers should be building the thing that passes these test cases.
  • Figure out who the real customer is.  You may not be able to control this much, but sometimes the person pretending to be the customer isn’t the person who will actually use the product.  If this is the case, you have to find a way to solve this problem or have a good representation of the real customer.
Advertisements

Responses

  1. Great analogy!
    Will certainly include that in my repetoire for agile evangelism!
    Thanks
    jonas

  2. I agree that constant communication between engaged product owners, business stakeholders, and the team is the key to producing the “right” solution for a backlog item problem. A short “design session” to set approach and then several follow-ups as necessary is a good way to keep the process light and still make thoughtful deliberate progress towards a good solution.

    I think the biggest challenge is balancing the inherently vague requirements available at the time the team takes a backlog item with the need to avoid having the story morph into something other than what the team agreed to take. The team and product owner need to come to a concensus regarding when a backlog item has gotten “too big” or has changed “too much” to be considered the same thing the team agreed to in planning.

    The team needs to be mindful of the possibility that “being open and flexible regarding requirements” can mean “the product owner didn’t get the backlog item properly described and the story properly written before asking the team to take on the work”. As new requirements become known during the sprint, a thoughtful discussion needs to occur between the product owner and the team to prevent this kind of scope creep.

    • Good point. I think one of the best ways to insure that the scope doesn’t change on a backlog items it to make sure the backlog item is vague in terms of implementation, and very specific in terms of the problem which needs to be solved.

  3. […] wrote earlier about how to hang a picture, as an analogy to completing using stories in an Agile way.  That example happens to be a good […]

  4. Fantastic way to explain Agile. Thanks for posting it.

  5. […] requirements the customer gave you upfront, or you tried to interpret.  Take a look at my post on comparing user stories requirements gathering to hanging a picture for more on […]

  6. I’m in the middle of an “Agile” project where I’m just an observer, learning from the “experts”, I was listening the user who multiple times explained something he wanted but seems that the agile team was not getting… just remind me your post, I bet he (the user) will get a bunch of holes in his wall.

    Great post!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: