Whats a good process for writing story cards?

Question

We are just going through defining our story cards for the next project.

• We have a good idea what the customer want through workshops
• We have a business requirement document that will be signed off by them.

Our proces of defining storys is as follows

1. We take a feature the customer wants and write a story
2. We have a brief design discussion amognst the team
3. We then determine an estimation for the card
4. If the card is longer than 3 days we break it down further and we reapeat from step 2

Unfortunately the customer wants an estimate of how long it will take for the entire project so we need to define all the stories up front.

This takes a while and can be quite draining

What other methods can be used to define the story cards? This can take What other ways to you gather requirements onto story cards?

EDIT:

1. This is not the first time we have done this it is, the normal process
2. The customer is an internal customer
3. I'm interested in how you write the cards that you end up coding against

Answer 1

How are you planning on releasing the application to the client? Are you doing incremental deliveries? Or is this planning for an initial deliverable?

I suggest breaking down development into two or three week long sprints and then add on an extra week for each sprint into the delivery budget to buy yourself some extra time... just in case the client changes their mind about a feature (they will). This will hopefully make estimating the final delivery date easier...

If you can convince your client that you should deliver incrementally you'll find that you will create fewer redundant stories as the spec changes. Plus, you won't have to do so much upfront work, and as development progresses you can write the next batch of stories while development is underway.

I hope this helps.

Answer 2

I would suggest something we called a "release planning game". It's very similar to what you do for an iteration, however, we did it at a higher level. That is, we would take the set of features or function points the user wanted for a particular release, and estimate knowing that we were going to be way off. You can then add all those estimates together to get a rough idea of when you think, based on your current information, you can deliver your product.

This should give your customers some idea of when you are going to release, but you still have to insist you need a little but of wiggle room because, like your customers, you cannot predict the future (or at least I can't).

Answer 3

I typically only ask for story titles upfront. I try to see if I can triage them to at least within an order of magnitude. I give a very rough estimate based on the number of titles and my estimated velocity/title. I'll usually have the customer break the titles up into (1) need to have now, (2) needed but can wait, and (3) these would be nice.

I start by tackling group (1) and coming up with enough information to break them up into a set of releases. At this point I can usually give a better estimate by using the more detailed information to provide per title estimates. I only plan out the group (1) stories. If there are too many group (1) stories to fit in a release, we break it up into multiple, coherent releases/iterations.

When we get within about a month of starting on group (2) stories, I sit down again with the customer (in a more focused planning session, usu. talking to them all the time), to start the process over with the group (2) stories.

Stories that get added as the project go on get put into the right group and handled as appropriate for that group -- if it's current release, enough detail to work with, if later, just the title as a placeholder.

The other thing that I do is make sure the customer understands that it's a cooperative process and we will end up with what they want. They get to choose when to stop -- even if there are stories left on the board. As long as I'm delivering value that they care about, we keep on developing. They need to trust that I'm doing what right for them and working diligently. I need to trust that they will give me the best information they can on what they want as soon as they possibly can.

Answer 4

You can't know when everything will be done and still follow an agile process. Even if you work very hard to estimate everything, the larger the work the larger your error percentage. Most estimates for projects of medium size end up being 2x off, and larger ones up to 10x off.

Instead, I would ask the customer for a functional target date. The conversation goes like this:

You: When do you need these features?

(C)ustomer: When can you deliver them?

You: Let's frame up the boundaries first. If I delivered all these features in 10 years, would that be too late?

C: Of course.

You: If I delivered all these features tomorrow, would that be soon enough?

C: Of course.

You: What about 1 year from now?

C: That's still too late.

You: 3 months?

C: That is just a little too late, more like 2 months. We have to be ready to use this with our Management team in January.

You (think): Ah ha!

You: We can't deliver all these features in 2 months. I think we could deliver these 4 stories in 1 month, and these 3 stores in the next month.

C: We'll we really need feature X for January.

You: OK, if we add feature X we'll need to remove a feature. Which don't you need?

C: We can do with only part of feature Y.

You: OK. We'll take this list and work up a more detailed estimate.

C (think): Ha! I got what I wanted!

I've found over and over that the underlying reason for estimates and planning "everything" is that they want a promise of delivery of something by a date. Working through the target date works much better because it:

1. Forces the customer to help make the trade-offs

2. Exposes the real reason for estimates

3. Reduces the number of things to estimate.

4. Helps identify which features are important to which sprint.

Answer 5

If you're trying to be true to XP then I would suggest you go here and read up on the difference between Release Planning and Iteration Planning. You shouldn't be doing individual task estimation until you're ready to actually start coding.

Stories != Tasks. Stories are broken down into tasks, that you then do the < 3 days estimation for. Estimating stories is more open and you should be able to decide on the thresholds for story estimates that work best for you and your team after you've done it for a while. (IE < 1 week, 2 weeks, > 2 weeks, etc.)

The most important part of estimating is following up with actual time spent, and making adjustments to your estimation process. XP is all about feedback.

Answer 6

I wouldn't break stories down this small for release planning (which seems what you want to do). Release planning will be less accurate, anyway (because things will change over time), so it makes sense to use a less accurate unit for estimation.

We typically use Planning Poker with 13 or 21 being the biggest allowed value before a story needs to be split. For release planning, we estimate in "ideal days", for iteration planning in "ideal hours". Works well for us.