Questions: Agile Release Planning

Question:

Hi Joe! Hope you are well. We are cranking up the Agile Scrum. I know you are likely very busy, and I tried to find answers to my Agile Release Planning questions below, but I am not finding what I am looking for on the net.

That said, I have three quick questions that I think are somewhat specific and hopefully you can answer in two minutes or less. We are following your lead and implementing ARP, but in our two pilot projects we had some confusion and overlap.

Using this ARP chart you did for us as a sample exercise:

1. Roles: Is this meant to mean:  Identify what “user roles” need to be accounted for so that when you write stories all “roles” are included?  As a _____, …
2. If we had 50 stories, or created 50 stories should we “target” completing Planning Poker for all 50 stories, or is Planning Poker optional at ARP since you have the arrow pointing towards — a SP?  If we did do planning poker at ARP, would we do it again at Sprint planning?
3. As a best practice, should we have or add Acceptance Criteria to the stories during release planning? My thought is, “No, not really required across all stories at ARP, more targeted for Sprint planning.”

Thanks in advance Joe.

Regards,

Michael

________________________________

Answer:

1. Roles. These are the roles of the end-users of the product. These are NOT the roles in the Scrum Team.
   So, we often think of them using words like ‘actors’ or ‘personas.’ And, yes, these roles (I suggest you want five to seven of them) are used in the first part of the user story format (e.g., “As a [roles x], I can…”).
2. Planning Poker. Yes, we want to do Planning Poker for all the stories we initially identify in the Agile Release Planning day, and I suggested that for about six months worth of work for one team, the right level of granularity would be about 50 stories. So, yes, for all 50 stories. This should take about 60 to 75 minutes. In other words, they do it fairly quickly. Why so quickly? (Well, to be honest, some people experience this time as slowly, and others feel it is much too fast.) Why so quickly? In part because they will learn more (e.g., as they complete the ready, ready criteria for each story) and as they learn more, from any source at any time, they can re-vote on the story points for a story. The typical time to do that would be in one of the weekly release plan refactoring meetings. Remember, they are definitely expected to re-vote some stories, and they are not expected to re-vote all the stories every Sprint — just the ones they think they are smarter about. Typically that would be the ones about to go into the next Sprint — not all of them, but some of them, or ones where we have notable new learning.
3. Acceptance Criteria. This term is used many ways. I think of the acceptance criteria for a software story to mainly address, at a high level, the basic tests for that story. No, I do not recommend, in the initial Agile Release Planning day, to identify all the acceptance criteria for each and every story — that’s a lot of work.

But, as the team is voting on some stories, they will identify some of the acceptance criteria. When they do that, someone should write down those ‘assumptions’ (and any others), and if the assumptions change that story should probably be re-voted.  Later, as the stories are being ‘explained’ in the release plan refactoring ‘red zone,’ then all the acceptance criteria should be identified (typically one of the first things done when a story is ‘groomed’), and other information is gathered for that story as well.
If that new information impacts the ‘sizing’ of the story, then that story should be re-voted. Anyone can suggest to re-vote a story. Some people go a bit crazy and want to re-vote too much, and some teams do not re-vote enough. A good ScrumMaster helps the team find the right balance.

You did not mention Business Value Points, but I wanted to add that we want to vote BVPs on all the stories on the ARP day. The BVPs and the SPs enable us to calculate the R factor for each story, which is key to ordering the Product Backlog better. (You will recall that the R factor is not the only driver of the ordering, but one of the key ones. The basic ROI concept. Do the highest ROI first — a basic business principle.)

Enough?

Thanks!

 

 

« « HBR on Agile! May Issue. || Topics for the Executives (managers) » »