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 2 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 --à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 5 to 7 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 6 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 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 'developed' in the release plan refactoring 'red zone,' then all the acceptance criteria should eventually be identified, as well as lots of other information about each story. 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 is 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!    

Release Planning: Summary of our blog posts

Here are the main ones, in order.

• Joe's Approach to Release Planning
• Agile Release Planning Vision  
• Agile Release Planning Product Backlog  
• Agile Release Planning Business Value 
• Agile Release Planning Effort 1
• Agile Release Planning Effort 2
• Agile Release Planning Risks, Dependencies, Learning, MMFS
• Agile Release Planning Completing the Plan 
• Agile Release Planning Refactoring the Release Plan

Some additional related posts:

Agile Release Planning Workshop Kent McDonald on Release Planning The Term 'Release Planning' Is Release Planning Worth It? Agile Release Planning is not about the Plan Release Planning with Business Stakeholders ALN RDU: Joe's Agile Release Planning Why Release Planning? Scrum and Release Planning Release Planning Release Planning & The Early Warning System Why I Prefer 'Release Plan Refactoring' to 'Grooming' Two Levels of (Agile) Planning Planning Poker - 1 Estimating Initial Velocity Wide-band Delphi Estimation for Business Value - 1                

Wide-Band Delphi Estimation for Business Value - 3

This is the third in a series of three.  See part 1 and part 2. ***

How can we use the BV points

We could organize the Product backlog strictly by BVPs, at least initially.

In fact, I recommended this, to see patterns or to make any mistakes obvious.

But I do not recommend doing the work in the order of the BVPs, the story with the most BVPs first.  This is much too simplistic.

The key thing we are missing is cost.  For centuries now, man has talked about the trade-off between costs and benefits.  And in business we have the concept of return on investment.  You invest $1000 (the cost) and get $2000 back (the benefit).

Can we use that concept here?  Yes!

For each story, we can calculate an R factor by dividing the BVPs by the SPs.  This gives us a rough ROI for each story. We could call it CBA (cost benefit analysis, or bang for the buck).

We think this is useful.

By no means does the R factor completely determine the order of the Product Backlog, but one can readily see that following the R Factor could help us maximize the business value per release, other things equal. (Of course, other things are not always equal, but we will not try to address that here, except to say that the Product Owner or others must re-order the Product Backlog some to account for the other things.)

What is the value of a BV Point

Sooner or later someone will ask: What is a BV Point worth?

At first, it is relative, strictly relative.  That is Story X is 50 BVPs, which means it has half the value of the reference story (which has 100 BVPs).

But let's imagine a very simple situation and see what it shows us.

Imagine a product backlog.

Imagine it has a total of 1,000 BVPs across all the stories.

Imagine that we know that the total Product Backlog is worth $2,ooo,ooo.

In that case, we can calculate that each BVP on average is worth $2,000.

You can't cash in your Story cards at the bank for money (based on the BVPs on each one).  You must release and there are MVP or MMFS issues as well, but one can at least feel (fairly accurately) that the BVPs are not just fantasy, but actually a foretelling of a future reality.  Well, if the customer still wants it when we deliver, and if we had good BV estimators.  

Objectivity and Visibility

In our opinion, whatever business value is, it is ultimately in the mind of the customer, and in the future.

So, to us as business people trying to solve a business problem (help people and also not go bankrupt), this seems altogether too subjective.

The BVPs start to make it a more tangible thing.  And this helps.

Whatever number we decide ob is then no longer a 'feeling' inside us (or one of us), but rather a number 'out there' on the story card.

This helps.

It helps in many ways, but let's give one example.

In former days, we would ask two experts for Story X: Is it high, medium or low?  And of course they would both typically say high.  Now, we ask the two experts to vote with cards. One says 21 and the other 89.  We and they can quickly see that one high is not another high.  And they can start to have the famous conversation about how high is high.  We can laugh, but actually this is a useful conversation.

In fact, one of the most valuable things about the numbers is that it makes the conversations better.

Tacit Knowledge

We just gave the example of the more useful conversation that arises.

When they vote, and they disagree significantly (wider than 3 Fibonacci cards), we want the two extremes to talk. Others may talk as well.

What do they talk about? Well, we think it is best to think of this as sharing the Tacit Knowledge.

One definition of tacit knowledge is "all that stuff we know, but we don't even know we know it, and it has not been made explicit it."  And, obviously, this is knowledge that we think is relevant and even useful in a given domain, or to accomplish a given set of work.  Explicit knowledge is knowledge that has been written down or put in a formula.

Do you want a Team to share their tacit knowledge?  Of course! In all the relevant domains.

Is it easy to get them to do so?  NO!  It is extremely hard.  In part because they don't know what they know, and in part because each person doesn't know what the other people are missing.

Priority poker forces them, in a fun way, to share the tacit knowledge.

In my opinion, this is the most valuable thing about the whole exercise.  Not that other things would not justify it.  But the sharing of the tacit knowledge is the single most useful thing.

Helping the Product Owner

Priority poker makes the PO job easier.  And it is a very very hard job, so any help is welcome.

In what way? Without priority poker, the PO had to make tough choices in ordering the Product Backlog.

Let's assume, in former days, that he talked to all the business stakeholder individually.  And they disagreed, of course, on the values of different stories.

So, the PO has to use up his political capital in just saying: This story is #1, this one #2, etc, etc.

This was 'risky' and often there would be some tense conversations. Too often the PO would be wrongly overridden by one or two business stakeholders.

Now, with the priority poker, all the business stakeholder educate each other. (Again I say, bring the popcorn.  This is fun to watch.)

Still sometimes, in relatively rare cases, all 4 of the business stakeholders are being stupid at the same time, and the PO's number will make only a small difference in the average.  And let us assume the PO's number is right.  Only then does the PO have to use political capital to 'move' the story to a more correct BV number or more correct ordering.

This reduction in effort frees the PO to focus his work in other areas.

Overall benefits

I want to reiterate the key overall benefits I mentioned earlier.

• They all see the same elephant (better)
• They all are more motivated
• They all have shared the tacit knowledge

If priority poker is done with the implementers, these benefits accrue to the whole team.  And remember that motivation is not just a 'feel good' thing; higher motivation directly leads to higher productivity from the Team.

I hope you try priority poker soon.  And tell us how it went.  I hope you will tell us how much it helped you.  

Wide-band delphi estimation for Business Value - 2

See Part 1. ***

Step by step

Let me walk through how I do it.

1. We have a product backlog.  Usually user stories.
2. We identify the right people to be the business value experts. We recommend that they participated in developing the PB.  Typically 5 people.  I call them the business stakeholders (maybe not what your company means by that word...just the key people to do this and participate in the Sprint Review) and the Product Owner.  The 5 best experts. (Sometimes you have 4 people or 6 people.)
3. We discuss BV drivers.  To make the concept of 'business value' more concrete in this specific situation.
4. We choose the highest BV card.  We give it 100 BVPs (BV points).  It becomes the reference story for BV.
5. We select cards randomly.  And compare them to the reference story.  The experts vote on BV using the Fibonacci cards.  I recommend the full true Fibonacci series up to 144.  If you want to add some cards at the high end (some, not many), I think it will not hurt.
6. They discuss and then 'secretly' vote. 1-2-3 show.  Everyone shows his poker card.  If the cards are all with 3 Fibonacci numbers of each other (eg, 21-34-55), then sum the cards and average to the nearest integer.
7. If they are not close, then discuss (especially the highest and lowest voters), enough so that the 5 voters learn something.  Then re-vote.
8. On average, allow about 1 minute per card.  Maybe slightly more. They will discuss the first few cards more slowly than that, and the last half of the story cards will go more quickly, on average.  Do not let them get take more then 75 minutes for 50 use stories.  Go fairly quickly.
9. When you are done as a team, then arrange the cards of similar BVPs.  And you ask the experts...do you see any cards that now look 'out of kilter?'  Often they will identify a few user stories to be re-voted. And then they do that.

That's the basics.  Pretty simple.

Results

I have never seen any set of experts vote all the user stories or even most of the user stories as 100 BVP (on every one).  In fact, they always use a roughly even distribution from 100 to about 5 or maybe 2 BVPs, across the set of stories.  This is quite remarkable, when you think of what we used to do.

Comments

I recommend that the BV experts think mainly in terms of 'wow factor.'  That is, BV is what will make someone (eg, the customers) say 'wow.'  Or say wow more loudly.  the louder the wow, the higher the number.  The experts often talk about dependencies (of one type or another) and want to deduce that the one card on which many other stories are dependent -- that card must therefore have the highest BV.  I discourage that way of thinking.  I recommend handling dependency issues a different way. If they need a decision about what a story is (or is not), the PO is the final decision-maker.  We hope, of course, that the PO uses common sense. We recommend you use a ScrumMaster (or someone like that) to facilitate the meeting.  Keep them at a good pace.  Let the quiet ones talk more, get the talkative ones a bit less verbose. I like to let the implementers listen.  They learn things. And I like to let the implementers, occasionally, ask questions.  "Why is that story so important?"  "I thought that story would be more important...can you explain?"  And the experts take a minute or two to answer.  But, we cannot distract the experts too much. The voting is very interesting to watch. Bring popcorn.  You could even sell tickets.  The experts will disagree with each other, and educate each other, and learn things about business value.  And they will complain that it is hard to estimate the future.  The implementers usually find it amusing when they say that, because these are the same 'jerks' who 2 weeks ago 'beat up' the implementers for not being able to estimate effort more accurately.  They start to respect each other more. The implementers learn a lot about business value, as they watch. This changes their motivation and it will change their behavior when they build the product. Are the experts really expert?  In my opinion, we can say that they are the best people we can find to make these guesses.  But they are really guessing what the customers will want when we deliver the product and for the 2-5 years after that.  No one is really an expert about the future. Still, business has always been risky.  About all real business questions, we get the best people to take their best guesses, and we hope that will give us more success than our competition.

Wideband Delphi estimation

This has been a commonplace idea for many people for decades. And used in Agile for estimating effort for at least one decade. And only talked about in Agile for estimating business value for a few years. See Wikipedia's article here. See James Grenning's article here.

9 Key statements about estimating

I won't explain them now, but here's the summary...   

1. Estimations can be mis-used by some managers (and have been).  Watch out!

   
2. Customers want some kind of estimate. (Ask for their details about what kind of estimate they want.)

   
3. There is a trade-off between the time it takes to estimate and relative accuracy.  Keep it shorter (usually) (of course, that depends on how short you were thinking...).

   
4. Always re-estimate.  Usually many times.  And arrange things with the 'customer' of the estimate to expect a re-estimate.  Make it easy to re-estimate.

   
5. Re-estimate when you are smarter.  Devise things so that you get smarter

   
6. Always discuss the variability of the estimate.  At least in some way, with the 'customer' of the estimate. ('I can promise 2015, but I can't tell you which month.'  A small joke, illustrating the range method.)

   
7. People can learn to estimate better, and faster.  Sometimes they start out terrible.

   
8. It is not the plan, but the planning.  We (the Team) get so many wonderful outcomes while we are planning.

   
9. Estimating can be fun, if you do it right. (But expect many teams to start with latent fear due to #1.)

Interested in your comments.

Bonus points if you notice a reference to John Legend.

Can the Team promise a date?

I think this is an important question.

Promise.  Umm.  What does promise mean?  Can Joe Namath promise a Super Bowl victory?

(I think he said 'guarantee'... and, oddly, his Jets team did actually win it.)

***

Let's say you have a fairly big project, that maybe requires 3 releases that happen every 3 months.  So, overall, a 9 month product before it is 'fully' built.  (IMO, no product is ever fully built; the customer always wants more.)

So, it is what I used to think of as a normal situation.

To make it easy to describe, let's imagine we are at January 1, and the releases will be March 31, June 30 and September 30.

In this situation, can the Team promise on Day 0 (Jan 1) that the releases will happen on exactly those dates?

Well, maybe they can.  In other words, they can say "We will release on those dates, and we can give some rough ideas today what the functionality will include, but it may change some."  I think they can usually or often say that.

Will change happen?  That is about the only thing that is a 100% certainty.  (Ben Franklin said death and taxes were certain, but Buddha said "Everything changes, nothing remains the same.")

For certain, some bad change will happen.  We will disrupted.  People will be 'taken' from us, in some form or another.  Important features will be discovered later.  (BTW, discovering important features is only bad when it happens 'later', and really only because it leads to a delay, and we have a weak mechanism for doing the customer trade-off between delay and the value of that feature.)  Etc, etc.  What is uncertain is how much 'bad' change will happen.  But, we will certainly have some bad change.

If we are professional, we will also have good change.  What is that?  Well, we will learn.  We will become smarter.  We will remove impediments and become more productive.  And, if we generally professional, this good change is certain too. What is uncertain is how much good change we will have.

***

Can we make a useful prediction of the release date for every product?

This is a very hard question, since no one can even imagine 'every' product.  But it certainly sounds like the answer must be 'no'.  One can imagine situations of many unknowns, extreme change, etc, etc.  We can issue a prediction, but, at least for those 'hard' products, it will turn out to have been useless or worse.

So, 'useless' predictions are possible, I think.

But, does the 'fact' (well, we posit it as a fact) that some predictions will be useless make all predictions useless?  I think not.

How accurate does a prediction need to be to be useful?  Well, I find most business people do not need that much accuracy.  They completely understand risk and uncertainty.  But they want some better information. Often they will say 'can you get me better information than the competition has?'.... a very low standard usually, but when we say it that way, you see how they will use the information.  They just want to improve their odds.  The odds of success, and also the odds of not losing too much on a gamble.

***

Now, back to the Team's point of view.

A promise is not a guarantee (Joe Namath not withstanding).  A prediction is an educated guess about the future.  And, as any adult should know, to predict is difficult, particularly of the future.  (That's a variation on a quote from the Latin.)

Can managers mis-use a prediction?  Most certainly.  And some people called managers have brutally punished the Team when their forecast was not accurate.  This is not right.

Typically, managers should not even see the Day 0 prediction.  But, after some small number of sprints (given something like a 9 month situation), most Teams should be able to give a reasonable prediction.  It is never a guarantee, because something weird could always happen. But it is usually a useful business prediction, that can enable useful business decisions.  Decisions by managers or decisions by customers.

If you are in the Team, when should the Team 'issue' these predictions?  Well, that is a very hard question, that requires lots of judgment.  It depends.

It depends on whom they are talking to. How much that person (that group) understands that things might change.  How much we have learned.  How much uncertainty this product has compared to others.  How close it is to the release date.

There are many factors.

But, as a coach, can we in fairness suggest that Apple never tell the customers anything?  Should we suggest that Apple actively deny any rumors about a future iPad?  And say, 'we have no idea when the next iPad might be ready?'  (Today Apple is expected to announce a new iPad.)  Apple should never tell its suppliers when to expect to start building the new iPad.  Never tell its managers when the basic development of the iPad might be done? (So that the managers could talk to the supply chain.)  Clearly, in business, some predictions must be made.  It is just required by business.  If the company and 'rumor' does not make a prediction, then the people themselves will, and often a very wrong prediction (too early or too late).

And, of course, some understanding of the degree of uncertainty needs to be communicated, if the person can listen to it.  Sometimes we use a percentage. Sometimes we use a range.  Sometimes we use only non-denial of 'rumors'.  Or just words ('we think it will be announced in the Fall of 2014').  But we urge you to help those you are working with (eg, help your customers) by giving them some sense of the degree of uncertainty.

The uncertainty can vary quite a bit, from one product to another.

***

In summary:

1. Be careful making predictions.

2. Sometimes bad things can result from making predictions.  (Ex: Some teams have, to my horror, been forced into a Death March to make some 'predicted' date. Unbelievable that humans would do that, but it has happened and continues to happen, we think.)

3. Again, do not make predictions lightly.

4. You usually must make a prediction at some point.  People will require it; it is the nature of life.

5. Try to assure that the person understands the uncertainty in every prediction.

6. Try to establish that a new and better prediction will be made later (when you are smarter).

7. Accept that life has risk. ie, Make a prediction.

8. Learn to make useful and relatively accurate predictions.  The best way to learn that is to ... practice.  By making real predictions, and seeing how life turns out.

9. Never pretend that a prediction is a guarantee.



 

Can we make a promise?

Well, can we?

There are some who do ‘waterfall’ (well, to be fair, something very roughly like the waterfall that Dr. Royce defined in 1970), and some of them seem to believe that we know enough early on, and change will be small enough for the rest of the effort, that we can promise a relatively precise date at the very beginning.  And reliably hit it.   And then, if we do not, they blame ‘scope creep.’

There are some in ‘agile’ (again, we must qualify it) who seem to think that change is always so large and we know so little up front, that we can never promise any release date for our product.  Not at the beginning, and not even along the way.

Of course, we have to agree that the dumbest day of the project is Day 0, at the very beginning.

Next, let us first recognize how important an early release date is.  It is very important to our customers, and it is often extremely important vis-a-vis competition and other factors.  If we release earlier (eg, on time), then the present value of the business value we will earn will be greater (assuming other things roughly equal).

So, clearly there is a great need to release earlier.  And, along with that, although arguably not as much in every case, a need to predict the release date earlier.  And with reasonable accuracy.

Can we do that?

The short answer is yes, to some degree.

In Agile, we can do that, in my opinion, somewhat better than we did in waterfall.  Which also means, still, not all that well on Day 0.  We still have problems in predicting the future.  We know the detailed requirements will change, in many ways and for several reasons.  We know both good and bad change will happen.  It does every time.  The only question is how much things will change.

Still, after some time and experience and learning, we can make some prediction.  And often, with a reasonable contingency, we can hit that date.

(I do not mean to suggest that the first attempt at predicting the date is accurate enough.  That itself is an important business decision — when do we feel we are accurate enough?  (after adding some contingency). Very good and difficult question.)

Can we predict ‘accurately enough’ every time?  Of course not.  And there are many reasons why.  Sometimes we get hit with the ‘Japanese tsunami’ of change.  A lot more change than we could have reasonably predicted.  And then, usually, other people will fully understand if we do not deliver on time.

In another scenario, it is often not one piece of change, but the accumulation of multiple changes that overwhelms us as a Team.  And, because it is not one big public change, but rather many factors, it is harder to understand from a distance.

Some situations are by nature more variable, subject to greater amounts of change (ex: subject to more learning about competition).

Still, even so, predicting, and using the information and learning we get from planning, can be very useful.  It can give us a better basis from which to learn more, in many dimensions.

Finally, one more factor that must be managed well (and often is not).

We need sustainable pace.

First, it is a moral issue.  We cannot treat people as slaves.  Second, we must have sustainable pace because it will make things better.  A pace that enables people to rest, and then, when they are working, to give their best creativity.  So that the innovation is more impressive.

So, what is the problem?  Well, we also know that people need some pressure, some challenge, to do their best work.  And we also know that many many teams, if the deadlines are tight and people say ‘go fast’, the Team often hears that as ‘cut corners.’  In other words, build technical debt.  Write sloppy code, let bugs in, do not document enough, do not refactor anything….and many more bad practices.

So, we the Team, we the Product Owners, we the managers, must be very careful in agreeing on dates and how we talk about this stuff.  Or you will quickly have a buggy ‘legacy’ system, and everyone will resign from over-work.

And it is hard.  You should (in my opinion), ask for dates and predictions.  And the Team needs a challenge.  But we must also talk about sustainable pace, about simplifying the work we do (smaller features), but NOT about cutting corners on quality.  Or maybe better said as ‘still, what we do build, it will be of good technical excellence.’

I will not talk here and now of how we keep our promises.  I have hinted already that breaking down the features and doing as little as necessary on the ‘big’ features is key.  Fixing impediments is key.  And identifying the minimum marketable feature set is key.  And hence, making the right trade-offs is key.  This includes cost-benefit trade-offs.

There is an art to doing the continuous research more effectively to make and revise ‘promises’.
And there is an art to working with the Team to change numerous factors so that we can improve the probability of keeping our promises.

People care about time.  Tempus fugit.

Agile Release Planning workshop - Comments

I have many comments to add to the blog, and many topics to discuss.  Let me start with this one.

Last week we had another Agile Release Planning workshop, in Montreal.  (We do one almost every week.)  The workshop is mainly about taking a real set of work (about 6 months of work for one team), and doing real agile release planning.  This is explained in this blog, and at LeanAgileTraining.com (for any specific workshop), and in my book, Joe's Agile Release Planning.

First, most everyone in the group said 'this is the best' or 'this is when it all came together'.  These are frequent comments from the workshop.

Today, let me talk specifically about Serge and his team, which were all from one company.

They took a brand new set of work, which the company has to do soon, and planned it out.

It was so good that Serge took the release planning information (the product backlog, etc, etc), back to the office.

***

They had two issues that struck me.

One:

They are used to developing the backlog in isolation from the Team, by one or two people.

And, to be fair, many of the people in the workshop were not members of what will be the real team.  Still, I think Serge started to see the value of creating the backlog with a Team.  And the team members did too.

And, later, all the individual detailed work could be done.  Research, cross-checking, etc.  So, the difference from what they used to do (have 2-3 'experts' develop the initial product backlog)....the difference ends up being mainly timing.  Now, the Team (with business stakeholders) does it first, and then the individuals can work on it later and make it better.

Why is this better?  Well, several reasons.  I will list two.

1. It greatly reduces the time before we start 'real work'...I'll call that real work 'writing code'.  And with code we can get feedback from 'the real world.'  So, instead of waiting 3 weeks before we can 'start', we can start the next day (well, honestly, usually it takes a few days more).

2. It enables the Team to have their hands in at 'the creation.'  This has two benefits.  One, it gets their creativity involved.  One consequence is that some of the 'missing' stories are identified now.  Two, it changes their motivation.  They no longer get the mushroom treatment.  And they start to see, by working on it, how all the pieces fit together.

The only downside is, this is a change, and to some degree some people may resist, and you have to explain it to them.  But I have always gotten people to do it fairly well the first time.  (Can you alone get them to do it the first time?  Maybe not.)

Two:

How to do Priority Poker?

In this case, the company has few 'business stakeholders' who will show up.  It is a small company, and one of the people who 'should' show up and do this is the CEO.  But he does not have the time.  And there is a sales person who also has some good insights, but who might take the Team in 'his own direction' ... we will say it that way.

And, Serge is right -- this is not ideal.  And, getting really good business stakeholders is hard and has problems.  Almost always, at least to some degree.

Still, we can get the ...well, best people we can get.  And then use the poker cards to vote, and then average the answers.  And put business value points on each story.

And, as is always the case, we will feel and in some sense know, that this is not perfect.  Except that, the BVPs are the best guesses by the best people we can get to do this at this time.

And then we can do things to improve the numbers.  Starting the next day, maybe.

One obvious thing in this case: Take the product backlog with the BVPs (business value points) and show them to the CEO, and then get his opinion.  And often he suddenly says something like "wow, I wish I had been there...I want to be there next time....but let's change the BVPs on these 10 stories."  And you realize that for 40 out of 50 stories, the CEO is agreeing we did a good job, and he is 'only' changing 10 of the stories.  And usually by not really that much.

AND...the exercise and the numbers enables the CEO to realize that he should act differently with the Team.  The information becomes evidence that causes him to change his behavior.

Well, I do not know that with these numbers and this CEO this has happened this time, but I do know that it can.  With the right CEO and with the right advocate.  (It may be that this CEO really really is too busy, for example.)

***

I hope these key observations (for me) also lead to useful thoughts and actions for you.

If you have questions or comments, please speak up (below or via email).

Question: Building user stories remotely...

Question: Hi Joe! Quick question - what have you found to be the best approach for creating user stories for the team members that are participating remotely? We have a release planning meeting for a group that has three team members in Connecticut and will be dialing in for the meeting. We have go to meeting and webex as options also. Thanks!

Answer:

I like to simplify and think of two parts.

(1) Initial Agile Release Planning, which is done in roughly one-day, upfront, as a Team plus business stakeholders.
(2) Every sprint, we have Release Plan Refactoring (aka product backlog grooming or backlog refinement.

For #1, really think it makes things much better in the long term to get the team (that whole group) collocated.  Yes, it costs some money, but it pays real dividends.  Your firm really must do that.

Now, I can appreciate that you cannot get them to do that, always.  Or the people just won't do it.  More on that a bit later.

For #2, I recommend 2 week sprints typically.  And if so, then 2 meetings per sprint to do RPR (release plan refactoring).

And I like to do RPR collocated if we can. But here, justifying the time and cost of collocation is not as clear.  So, you might do it 'remotely' as we say.

I do not care much which 'virtual meeting' tool you use.  GoToMeeting, WebEx, and others are very good.  I do recommend that you get at least one person on the call who understands that product well, and knows how to use it well (can make it work quickly) and can explain it well.  And get that knowledge spread throughout the team quickly.

Then, I like to use a story tool.  Again, there are many.  Trello comes to mind.

What do you want?

1. The ability for anyone to write a story, without waiting in line.  This enables a volume of stories to be done in a small timebox.

2. The ability for everyone to *see all the stories at the same time.

3. The ability to re-arrange the stories (in multiple ways) to see patterns and relationships in the stories.  (Examples: 'all in one module', parent-child, 'connected', same role, same department, business flow, etc, etc.)  This visual thinking often leads to more creativity.

I think Trello enables all 3 of these.  Probably other tools do too.  Certainly a physical board can support this.

I would use brainstorming rules for a good while.  Meaning mainly: 'any idea is a good idea; no criticism until later; we need a pile of stuff to work with.'

Related to this, identify to the participants what your goals are.  They include: a pile of stories (volume in a time box), clarity of the stories (although they may be rough at first and clarity may be added later), completeness (of the stories, given the timebox), inventiveness or innovation (something unexpected), learning across all team members, etc, etc.

How big a timebox for this round?  Well, you did not give me much to go on, but I will guess 30 minutes for this round.  Maybe extend to 45 minutes if everyone says they need it.  Set the outer boundary at 1 hour.

Does that help?

Estimating Initial Velocity

Here is a method for estimating initial velocity that may work for you.

I expect you to use it in the context of Agile Release Planning, probably as I define it.  But probably this is not necessary.

First we take some assumptions or identify the facts.  Imagine the following situation:

Implementers: 5

Sprint Length: 2 week

Ratio: 1 SP equals about 1.5 ideal person days.  (This is based on a sample from your product backlog or your reference story set.)

Focus Factor: 60%.  This means that although they are 100% allocated to the Team, as they work, they will only get about 4.8 good hours per day.  The rest of the time people are asking them questions, they are reviewing email, they are going to important company meetings, etc.

Start-up cost: 40% the 1st sprint, 20% the second sprint, maybe 0% the third sprint.  I give 3 reasons for this Start-up cost:

1. The team is learning Scrum
2. The team is forming, storming, norming, and then finally performing.
3. The team always wants to over-commit.  I find this to be the case.  Some people do not.

In any case, experience shows that taking out 40% then 20% then 0% is a good rule of thumb.  If your team is more experienced, maybe you take out less.

***

Now we start to calculate.

5 people and 10 days = 50 person days

50 X 60% = 30 ideal person days

30 X (1 - 40%) = 18 i.p.d remaining

18/1.5 = 12 SP for Sprint 1.

***

30 x (1 - 20%) = 24 i.p.d

24/1.5 = 16 SP for Sprint 2.

***

30/1.5 = 20 SP for Sprint 3.

***

So, those are quick guesses.  You can make the calculation more sophisticated, in the sense of catering for more factors (vacation, special situations).

In any case, these are still guesses.  You will soon discover the Team's real velocity from real sprints.  Use that soon.

Question: The Basics of Agile Contracts

Melinda asks this question: How can SCRUM/Agile Methods be effectively leveraged for responding to RFP/proposals for Fixed price & Fixed Date contracts especially when the SCOPE (I.e. Product Backlog) is more adaptive to change? When would CRs be required, if at all? How can we help customers understand and be confident that they will receive greater value for a Fixed Price & Fixed Date contract than the traditional Waterfall methods?

Answer:  This is a hard question, but I think phrased in a reasonable way.

Let's take one extreme.  If you have a completely unreasonable customer, who wants lots for nothing in no time, then nothing is going to fix that. Not waterfall, not Scrum, not Agile.  So, you have to start with a reasonable business situation and reasonable partners.

Then, for today, let me make these basic statements.

1. We can use Agile Release Planning (as I define that in my book and teach that in my course) to establish the scope and the date.  And also the budget. I believe you can do this better with these agile methods than with our typical waterfall methods.

2. I have assumed in the Agile approach, you have added a reasonable amount of buffer (cushion, contingency, whatever you call it).

3. We show the customer the product backlog and the business value points, and how we have ordered the work (in mainly benefit-cost order).  The customer can 'correct' this order (within reason).

4. Building it in Agile will be more effective.  We will understand better, and build it more cheaply.

5. If 'unexpected' changes are too great (we get a tsunami hitting our building), then we may still fail.  But bear in mind that the cushion should have been built for a reasonable amount of 'stuff' hitting the fan (that's the technical phrase).

6. You ask the customer: "Could you come in once a month (or whatever your sprint length is) to see the software we have built so far, and gives us feedback?  And if anything is wrong, not correct according to the spec, we will fix it for free?"  ('Wrong' means truly 'not to spec' -- they don't get to go crazy with 'implied' features.)  Any reasonable customer will jump at the chance to do this, since they know from long experience that the bad news does not get better with age.  Even though they understand that those meeting cost them something.

7. You ask: "Does it ever happen, when you examine the software, that you discover new features that you want?" Of course, that always happens, so they say 'yes'.  So, you offer them 'change for free' as explained below.

8. We tell the customer: "You can make changes in two ways. You can get 'change for free' -- meaning you can identify a new feature of 2 SPs (story points) and substitute it for an existing low value feature of 2 SPs.   Even exchange, aka 'change for free'.  Not additional cost.

9. The customer can also add a feature via a CR (change request), and we can price it at our usual (high) rates for changes.

10. Because both of these are open, the customer tends to argue that 'it was implied already in story 54' a lot less.  Of course, they still want and make changes for, mainly, the two classic reasons: (a) they think of it after they look at some of the working product, or (b) their business situation has changes some, and so the features need to change.

11. Speed of delivery. In the past, we as a consulting firm only made money if the project went long.  The original contract is always priced 'too low' because we have to beat the competition.  But once the customer is in bed with us, they have to use us for changes, so when they asked for CRs (and they always did), then that is when we could make some profit (finally!).  So, we wanted the project to go 'late' in this way.

12. But the customer always wanted it sooner. To be honest, they wanted it before they even asked for it.  AND...while they 'wanted' (or said they wanted) lots and lots of features, what they really wanted was something simple that worked, and did the most important thing(s) well.

13. So, we offer them 'money for nothing'.  Meaning: We offer them an 'end early' clause.  They have the option to cancel the contract at any time, so long as they pay us 20% of the remaining contract.

14. The key thing is that this aligns our needs (we are the consulting company or vendor) with theirs.  We both want to deliver fast.  Faster.

15. Example: The contract is $10 million and 20 months.  We complete 4 months (we have Pareto on our team).  That's 20% of the work. Over those 4 or 8 sprints, we have convinced them to take an early release.  The value of the work to them is much much higher than the cost.  So, since the first 4 months has the highest value items, the value of the features from the first 4 months is huge. (I won't do the math here, but you can guess at it.)  The customer WANTS to release early. Partly because we have seduced them with 'sizzling steak'.  (Some of you will know my 'killing babies or sizzling steak?' metaphor.)

16. The Money: For the 20% of work, that is $2 million. Leaviing $8 million in the contract. They cancel clause says they must pay us 20% of the remaining, or $1,600,000.  Money for nothing (we built nothing to get that money).  And the customer is happy to pay it to get early delivery of the high business value features.

So, money for nothing and change for free.  Easy to remember if you get into dire straits as a consultant. (Sorry about that.)

Let us repeat: If you have an impossible customer or an impossible situation, nothing is a silver bullet.  Still, this approach gives you far greater probabilities for success. IMO.

See also Jeff Sutherland's blog posts on this.  And his presentation.

Planning Poker Tools

Mike Cohn has the phrase ‘planning poker’ registered.  So, this is acknowledgement of that. And, like Kleenex, that’s what we call the thing itself.  It no longer has a generic name.

And, as some readers know, I like Priority Poker too.

So, for this post…. what are the best tools, sites or apps?

First, I like using the cards themselves.  This is great, except that the proper way of doing it, say with 5 people, is to average the numbers once they get ‘close’.  (We usually define close as ‘within 3 PP cards — ex: all votes are either 5 or 8 or 13.)

So, when using the cards, the hard part is addition and division.  Which I learned, but later got bad at.  Now, if you have Philip on your team (and Philip does addition and division wonderfully in his head), then you have no problem.  If your team is collocated.

But, I don’t always have Philip.

Here are some tools:
http://hat.jit.su  (thanks for Jaime Carter)
Planningpoker.com from Mike Cohn

And there are a host of iOS apps that I know of.  Maybe 15 different ones??

I am still looking for one to do the averaging for me.  But I like those those two sites above.

Comments?  Suggestions?

Agile Contracts – Question 1

Adela asks this question: Imagine we have a brand new project. And we must bid on it, and we want to use the agile-scrum method.  How should that work?

This is a good and a hard question.  I will answer it quickly here. Too quickly.  I have partly answered it in my book, Joe’s Agile Release Planning. And partly elsewhere.

Why is it a hard question?  Because business and life itself wants us to do what is impossible.  To perfectly predict the future. And to know everything in advance.  And, while we all forever will wish those two statements were true (well, at least part of each of us will), they never will be true.

So, let’s make the case fairly simple.  Imagine that the project (the work) is about what one Team can do in 6 months.

Then I recommend Agile Release Planning (as explained fully in my book).

The Team (including the right ‘business stakeholders’ or SMEs or customer reps or whatever you call them) do the following:

1. Clarify the vision. Quickly
2. Build the product backlog. In user story format. Roughly all that work divided into about 50 stories.  Not to large, not too small.
3. Identify business value on each story.  Via priority poker. Using the best BV people we can find (about 5 of them).  In about 1 hour.
4. Identify the Effort for each story.  Using planning poker. Again, using the right people for this (namely, the people who will do the real work).
5. Identify the R Factor (BVP/SP).  For each story.  Make the benefit-cost ratios more explicit.  Order the work now by R Factor.
6. Consider Risks, Dependencies, Learning, Min Marketable Feature Set, and other issues. Re-order the work as needed.
7. Do the scope-date trade-offs. In other words, identify the ‘release’ cut-offs.
8. Estimate the velocity of the team. And identify when each release will happen.
9. Do a communications ‘plan’ and add appropriate buffer (aka padding, contingency, etc.)
10. Identify the ‘fix it plan’ to fix the biggest imperfections in the plan first.
11. Start ‘release plan refactoring’ — where we refactor the release plan every sprint based on new learning.

Ok, let’s imagine further that the client asks for a fixed price.  So, after Step 10, we have to give a price to the external customer.

Now, the first time you do Agile Release Planning, I think you will get a better (slightly more accurate) scope-date-budget than you do using your current method.  Still, for the first or second time, I do recommend doing it both ways. And comparing the results, and learning from that.

By the third time, I predict that you will be happier with this agile approach than your current approach.

Will the agile approach on day zero ever be ‘perfect’?  No.

Always we guess at the buffer or padding. And always that guess can be too much (not a big problem if the customer agrees) or too little (a big problem if it causes us to go bankrupt). Notice that we as a vendor are biased to want to win contracts, and hence often ‘close our eyes’ and go with too little ‘padding’.  Often.

In any case, once we get a signed contract, I recommend running the project in an agile way.  Again, this cannot guarantee success, but it will enable us to manage the effort to better success (or a lower loss).

That’s the summary of my answer in one short blog post. I am sure I left many questions unanswered.

What does it mean to be 'Ready'?

Jeffry Hesse wrote this blog post. And it inspired me to write the post below.

The new Scrum Guide says that PBIs (product backlog items) must be well-understood and granular enough (just before going into) for Sprint Planning.  And that PB Refinement is the process we use to get them to Ready.

Those are not quotes, but that is how I read it.  I think accurately.

Jeff Sutherland and I and others advocate the 'ready, ready criteria'.  Roman Pichler and others call it the Definition of Ready.  I am ok with either phrase.

So, what is it?

Well, like the DOD (definition of done), it must be specific to each Team.  Each Team must define one for themselves.  And they vary some, depending on many factors.

We want the User Stories (or PBIs) to be more defined than they often are for some 'agile' teams.  But this does not necessarily mean the voluminous documentation that many waterfall 'teams' have. (I put 'team' in quotes here because I never find that waterfall teams have anything close to the team feeling of agile teams, especially a good agile team. Nor the productivity.)

So, 'ready' is kind of a Goldilocks concept (like most things in life): not too little, not too much, just right. A balance.  We definitely want to leave some room for the Team to be creative during the Sprint.

The ready, ready criteria are similar to the concept of GIGO.  Garbage In, Garbage Out. Or rather, obviously, the opposite. We want 'good stuff' going into the Sprint, so that 'good stuff' can be completed at the end of the Sprint.

I conduct courses and workshops all the time, and I ask people: what do you want in your 'ready, ready criteria'?  The context is: Imagine we are having a short meeting about 1.5 days before the Sprint Planning Meeting. What are the things you want to review to be sure the 'top items' are ready, ready?  And we assume a 2 week sprint, with about 8 small PBIs (stories) about to go into the next sprint.  (Yes, I am making lots of assumptions that may not apply to you...)

Here are some of the things they say.  This is a super-set.  First, any list would not apply to 'every' user story you have.  Second, for your specific team, you might make this list longer, shorter or just different.  Suitable for your specific situation.

So, here are some of the things I recall them saying (that I agreed with):

1. Is the US (user story) phrased well and completely (eg, the 3 parts)?  Do not forget the 'so that' clause.
2. Does it match the INVEST criteria well?  (You remember them: Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable.)
3. Small enough? (Sized appropriately should have done that, but let's emphasize that one. A key issue for most teams -- stories are not small enough yet very often.)
4. Acceptance criteria good? (These should cover the tests well enough.  If not, add another item.)
5. Story points still good?
6. Business value points still good?  (Relative business value points.  Explained elsewhere.)
7. Questions answered? (Reasonable questions from the Doers.)
8. Tech Issues addressed?  (One simple example: Android, iPhone, Windows Phone or all 3?)
9. Enabling Spec good enough?  (A whole other discussion. Not for now. The blog has a post on this.)
10. People-work match?  (Sometimes the PB has all Java stories for this sprint, but there is only one Java guy in the Team, and he is going on vacation for a week. Yikes!  Mis-match!)
11. We still agree this is the best work for the next Sprint?  (Best considering everything, but especially business value.)
12. Team Thumbs Up?  (I want everyone on the Team to give each story a thumbs up. This is a catch-all; if something is amiss that is not covered above, hopefully someone's thumb catches the issue.)

This of course is more work if we have just identified a new story (which should happen sometimes in real life).

If a couple of stories get rejected, the PO has another day to 'get his stuff together' to get them ready for the SPM (sprint planning meeting).

This meeting is one of the two meeting I like to have to do Release Plan Refactoring. This one is short-term focused. The other is 'long-term' focused. These two meeting go together.  We do not have one without the other.  We plan longer-term so that Sprints go better.  We do Sprints to fulfill the longer-term Vision. They go together.

This meeting (just before SPM)  requires that the PO 'get his stuff together' beforehand. For example, the acceptance criteria should already have been defined, and the question is: does the Team think they work?

And not all that work is done by him (or her) alone. But the PO is responsible.  It is expected that a few issues will be found.  The POs work is expected to be good, but not perfect. (Again, it is not solely the POs work; many others could have contributed.)

We have the assumption that every day we are learning, and every day things can change. Both for the good and for the bad, and for the 'bad' (eg, maybe good for the customer, but harder for us as a Team to deliver).  Hence, we have to have this meeting at the last responsible moment.  (Cf. the Poppendiecks.)  Just before the next sprint planning meeting, leaving some time for the PO to recover from some issues.

Are some of the issues or concerns above being addressed on other days during the Sprint?  YES!  By the PO.  In some one-off quick meetings.  In some pairings, maybe with business stakeholders.  Etc. Etc. Etc.  But this is the last time where the whole Team (together) reviews the stories about to go into the Sprint. It should be a fairly short meeting (about 1 hour).

Or, so I coach for most teams.

Are there other ways to do it?  Surely.  Are they more or less successful?  I don't really know -- I have not tried all the million other ways.  I see my teams having more success with my approach.  But honestly I do not have double-blind independent studies.  Do you?

***

Two points additional points:

The Team must be motivated to do this. And I would try to include some business stakeholders. By giving the Team the 'thumbs up?' vote, that tends to get their attention.

In a 2 week Sprint, I also like to do another meeting, in the first week, that addresses the Release Planning for the longer-term. That meeting is also typically about 1 hour. More on that later.

***

I hope you will give feedback. I hope you will try some of these ideas, and that they help you. And then give feedback again.

ALN RDU: Joe’s Agile Release Planning

I had the pleasure of talking with the Agile Leadership Network group in RDU tonight.

First, there were a lot of smart people there and I enjoyed it.

Here are some things I forgot to say or did not emphasize enough.

1. I have different goals that many have for what we call agile release planning. With different goals, we have different methods.

2. To me, the main goals include…

Increase the motivation of the Team (fingerprints, part of the creation)
Get everyone on the same page, seeing the same elephant.
Get alignment.
Sharing the tacit knowledge
Team building
Who knew the people were most important?

Yes, there are other important goals, but these are the primary ones, in my view.

3. I am NOT proposing a ‘one size fits all solution.’

I feel confident that my ideas for Agile Release Planning work in many situations, at least common situations that I meet commonly.

But I do not feel that these ideas fit all situations.

If they work for you, fine. If not, I am ok with that.  You should use what you think will work in your situation.

4. We need to keep it simple, as simple as possible.  This helps many things.

So, I have described it simply, perhaps too simply for some. And more simply than it really is in real life.

But if your team needs to add things or make it more complex, please do. It may be useful and necessary for you.

Again, what I am proposing may also not work for you.  It has not been tried in anything close to ‘every situation’.  Use judgment.

5. The hip bone is connected to the thigh bone.

Meaning: Everything we do is, to some degree, connected to everything else. For example, to deal with some issues, one can talk about a solution as part of ‘agile release planning’ or as part of Pareto-izing the work in the course of the Sprints.  To fully understand ‘agile release planning’ one must really understand ‘everything else.’ And yet, we never have time to describe ‘everything else.’

Perhaps the biggest things I want to add are these:

We hope the conversation helped us all to think more and better.  And that that, in some way, leads to better results.
We hope we mentioned some ideas that you try to do, and that some of them are useful.
Thank you!

Why I prefer ‘Release Plan Refactoring’ to ‘grooming’

I was just doing a course with Dave Muldoon in Canada. One of the workshops was scaling. In that context, we discussed release plan refactoring or product backlog grooming.

To me, the Scrum community has many definitions of ‘product backlog grooming.’ In fact, the community has many different words for it. And it is confusing, especially to beginners.

I like to use the phrase ‘release plan refactoring’ instead.

Today, briefly, I wanted to explain why.

But first, why is this question even important?  Because ideas affect actions. If we do the action without a deep understanding of the intent, we are very likely to do the action in an ugly way.

Basics

The bare framework of Scrum does not define ‘release planning.’ Nor does it define ‘backlog grooming.’ The latest Scrum Guide does have a few vague phrases like this: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process….”

My understanding is that Jeff Sutherland and Ken Schwaber are not against doing specific things and using specific words in specific situations. They just feel that they don’t want to include those things in the bare framework of Scrum. Why? Well, that’s a lengthy conversation for another day.

Probably not all teams need what I call ‘release planning’ — the short, quick up-front activity of defining a product backlog and guessing at what the next release or 2 or 3 might look like.  And maybe some other things. Not all teams need release planning I guess, but in my personal experience, virtually all teams the teams I have worked with have needed some short quick up-front release planning.

In any case, we have some sort of product backlog. And, clearly in real life and clearly according to the Scrum Guide, that product backlog must ‘evolve.’

What to call it

So, what should we call that activity that makes the product backlog evolve?  (Well, the true root cause of course is ‘change’ very broadly speaking.  But you know what I mean…)

PB Grooming:

To me that connotes two chimps grooming each other. I visualize grooming my face, or a man grooming his beard, or a beautiful woman putting on make-up, or grooming my toenails.
When I see ‘regular’ teams do what they call grooming, it is mostly these things:

• breaking down stories (or PBIs) into smaller stories (or PBIs)
• Identifying new stories
• adding Story Points to the new stories
• adding acceptance criteria
• more broadly: getting the top stories ready for the next sprint

And this is great. Very important. Useful, good.

BUT…incomplete.

Usually they are not doing, or not doing effectively, the longer-term activity of managing the product
backlog toward success in the release (and here I am assuming that it takes 3 to 10 sprints to build the release).

PB refinement (the term in the Scrum Guide), when people use that term and you watch what they do, they usually do (and say) about the same things as for PB grooming.

Note: There are many exceptions, of course, to how people use these terms. I am saying what I generally hear and see.

Release Plan Refactoring (RPR) – Why I like it

First, RPR suggests that the ‘whole’ release plan needs to be refactored.  In every way.

In software development, the word ‘refactoring’ has a set of strong connotations. Of professionalism, of robustness, of having to be on top of it all the time. But also of balance and cost-benefit approach and other things. Almost all of these things apply, at least by analogy, to Release Plan Refactoring.

Also, to me, RPR helps express, to people in the Team and people outside the Team, one key idea.

The initial release plan is never ‘good enough’, and we are always trying to make Release Plan closer to what we will do to make the release successful.  So they can say tp themselves: ‘yes we have initial release planning… but immediately we embark on continuous release plan refactoring to make the RELEASE successful.’

Release Plan Refactoring also includes the ‘getting ready for the next sprint planning meeting’ stuff too. It include the ‘short-term’ stuff as well.

To me, one of the key advantages of RPR is that it connects
(a) the longer-term thinking around ‘what does the release need to look like’ and
(b) the short-term thinking around ‘what will we do next sprint’.
To use two words, it connects tactics with strategy.  And both are required to be successful.

And my feeling is…
(a) we could try to re-define PB grooming or PB refinement to include those ideas of connection, so that the community ‘gets it’ better, or
(b) we can start using a different word (well, 3 words, RPR) to express that idea.

Clearly, I think (b) is the better approach.  Am I right? (You decide.)

Now, really, the words per se are not important. What is important is that people have the right ‘tacit knowledge’ when they take an action.  They need to know, when they try to ‘improve’ the product backlog (the release plan), why they are trying to do it, and how all the different things inter-connect.  For example, how the short-term stuff connects to the long-term stuff.  How tactics connects to strategy, if I may use those words in this context.

***

If you are interested, I discuss the practices more in my new booklet “Joe’s Agile Release Planning”.  Available here.