Pain is temporary, failure lasts forever

Lean, agile living for the running mother of Peter

2008-08-19

How do get some user stories on your backlog?

Believe me, I've tried all possible and impossible ways to get those stories printed. They all suck, in some manor. There is probably no such thing as a perfect solution. So, just drop that wish, and just try make the best of things.

The reason for writing in the form of a user story is that you want to catch the objective - what need do you want to forfill. Keep that in mind.

But then, take one step back and think: why do you need a product backlog? Well, you need to be able to tell the developers what they're supposed to build and you need to tell the users what they are going to get. And the things being done should be the thing that brings the most business value.

OK. Who should participate: well, first you need the guys who knows how to define the problem, and then you need the guys who are going to solve the problem. This means that you need some (representants for) the users and you need some developers. And then you arrange a story writing seminar. A story writing seminar means that developers and business people/users/stakeholders get together and try to get the problem needed to be solved printed in some form (digital or analog). If you are many: divide into groups. If you don't want to spend to much time: time box and keep the meeting standing.

I'm often asked: why involve the developers? Shouldn't they be coding? Well, to which use is the code if they don't solve the problem, and how great is the risk that they build the wrong thing if they don't understand which problem they are solving. That's why both groups are involved.

To make the meeting more focused and to have something to discuss around, I've created example scenarios. It's max 2-3 pages long and describes the types of users (personas are great for this) and what the surroundings for the problem is. For example, we're working in the field service management product business and an example scenario can be the small electrical firm who wants to report new cases while in the field.

All that want to participate need to read the scenario in advance and we spend perhaps two hours writing these short stories in the form described in an earlier post. But then you say: what about the details? That was like one sentence. That couldn't be enough for developing or estimating? Or could it?

Labels: ,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home