Agile Release Planning – Questions

QUESTIONS

Joe – during an agile release planning session how long do you estimate it will take for Business Sponsors to point approx 50 stories?

Actually, I’m estimating we will need 32 stories for 6 months. Yes, I’m looking to hold an ARP at the end of Feb for 1 feature.

Thanks, Craig

REPLY

First, why do I recommend 50 stories?

The 50 stories is in the context of 6 months worth of work.

I recommend 6 months of work because I think, from experience, that people LEARN ARP the best when the work is that size (that duration for the Team).  Smaller or Bigger, they start to learn it less well.

And the first two times for them, learning it well is a main goal.

I am also assuming a regular team (as I defined that), meaning a PO, a SM, and 5 implementers.  Not big but not smaller.

For 12 sprints, I’d recommend that we eventually have 96 stories (12 x 8 stories for the real sprints).  That’s 96 stories, when we get to the actual sprints.

Why 50 Stories

But I find the initial ARP, for 6 months of work, goes well with about 50 stories.  Roughly half as many as the 96. So, the stories we have today should each be about twice as big as they will need to be when the stories go into real sprints.  That is, ideally all stories for now are small epics.

Another way of thinking about the 50 stories is this – how many stories can a person hold in their “head” (and on the (virtual) wall) at the same time?  I find about 50.  And maybe NOT true at first, but after they talk about them all a couple of rounds, fifty fits rather nicely.

Note that the smaller the story, the more it is understood.  Its boundary is tighter, there is LESS wiggle room for guessing and different assumptions.  We will still have some of those problems at first, but the degree of those problems will be notably less.

They won’t actually create stories exactly and consistently that small epic size, but that’s what they should be trying to do.

And, it turns out that if they get to 50 stories, it never totally sucks.  It is a usable Product Backlog.  The very first time.  (They will create a better one next time.)  Frankly, I am now kind of shocked that every “team” comes up with a usable (not perfect) product backlog the first time.

I have changed my timing then a bit.  I want you to shoot for voting BV points on all 50(ish) of them in 60-75 minutes total time.  The first 5 or 10 stories will go rather slowly, and the later ones on average will be much quicker.

The timebox for voting

Let’s remind the readers: The voters for the BV points are the Business Stakeholders (as I call them) and the PO.  I want 4 BSHs and 1 PO….so 5 people are voting.  Five different opinions or points of view have to “fight it out”.  More wisdom when we put the heads of 5 “experts” together.  (And you do really want them to be expert in some sense.)

I want these to be the same Business Stakeholders that show up at every Sprint Review and give us feedback on the built stories. In other words, they are responsible for the consequences of their actions as a group.

For example, it’s not so bad if the initial BV points are deviating a lot from what they should be.  But if this is not corrected fairly soon, then the Team will be building the wrong stuff.  It will have notable business consequences.  In the Sprint Review an independent manager should see that people are excited by the BV of the stuff just built, and that should be confirmed when the next MVP is released to the customers.

***

Take notes.  Some of the discussion and assumptions and definitions of what is in or out of a story are worth tracking.  Often these will turn out later to be wrong, which means we must re-vote that story.

It is important to remind the voters:

1. This is your dumbest day of the project.  We do not expect the votes to be perfect.
2. We’re going to vote now, with the information you have now as a group.
3. Then we can prioritize the group’s stupidity (where we know the least).
4. We will get more information and further details will be added to the story.
5. Whenever you want to vote again (eg, because we have more information), we can.  Typically about twice for each story before it is built.
6. So, let’s do it fairly quickly this time, and then see overall, what we have.  And then improve it.

If you do not remind them of these things, some people in the group will want to go much too slowly.

 

« « BV Points – 1 || Renewing Your Certification » »