Comments on: How to Hang a Picture: Agile User Stories

By: berxpert

berxpert — Wed, 16 Mar 2011 04:52:22 +0000

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!

By: Agile Testing is Different « Making the Complex Simple

Agile Testing is Different « Making the Complex Simple — Wed, 16 Jun 2010 15:13:15 +0000

[...] 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 [...]

By: Patty

Patty — Wed, 14 Apr 2010 21:08:02 +0000

Fantastic way to explain Agile. Thanks for posting it.

By: Don’t Go Chasing Waterfalls (Mini-waterfall vs Agile) « Making the Complex Simple

Wed, 07 Apr 2010 17:42:55 +0000

[...] 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 [...]

By: jsonmez

jsonmez — Tue, 02 Mar 2010 21:44:23 +0000

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.

By: Evan

Evan — Tue, 02 Mar 2010 21:00:47 +0000

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.

By: Jonas

Jonas — Tue, 02 Mar 2010 20:14:56 +0000

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