joe’s approach to agile release planning v1-06

8/10/2019 Joes Approach to Agile Release Planning V1-06

1/28

Saved on 1/5/13 8:50 AM Page 1 of 28 Ver 1.06 copyright 2013 Joseph H. Little

!"#$% '(()"*+, -" './0# 1#0#*%# 20*33/3.

By Joseph Little

This booklet is almost solely about initial, quick, up-front agile release planning. For one

team. My usual way.

So, this booklet has a very limited scope.

The first thing to emphasize is what I call Release Plan Refactoring. This is the idea thatevery Sprint we refactor (as much as needed) the release plan to reflect all the newinformation.

* * *

This booklet is for beginner to intermediate teams. In typical situations. Your mileagemay vary (YMMV), as they say. Advanced teams may wish to try other approaches.

It discusses, in later sections, release plan refactoring the revisions to the release planthat should happen every Sprint. Some changes will be minor and some major. But it isessential that revisions be considered every sprint. Too many things are changing in the

real world.

This proposed approach is NOT for everyone. I am not trying to propose a one and onlyone pattern. Still, this is a pattern that I think works in most of my situations. But it

might not fit your situation.

I want the initial release plan to be done quickly, in 1 or 2 days, up-front given that itis for about 6 months worth of work for one team. (6 months worth of work is fairlyarbitrary, but typically also about the right amount for most common situations.)

To me, at least. I never believe in the initial plan. It must be improved many times; itwill never be perfect.

Note: Despite not believing in the initial plan, sometimes we are forced bycircumstances to make important business decisions based on the initial information or

forecast. I think we can do that to some degree, as I discuss some later. But these arerisky business decisions made with too little information. As most business decisionsare. If done with equal professionalism, I do think the risk is somewhat reducedcompared to a similar waterfall plan.

***Here are some values, principles and practices around agile release planning that I havetaught to numerous teams. In general, the teams have found them very useful. While you


2/28


may not find all of them useful, we hope at least they will make you think. And at leastthat thinking will make your results better.

4*)3/3.%

"#$ %&& #' (#) *++, $# ,# %-.&+ /+&+%0+ 1&%**.*-2 3#/ +4%51&+6 .' (#) /+&+%0+ +7+/(

01/.*$6 $8+* /+&+%0+ 1&%**.*- 9#/ % 1/#,):$ /#%,5%1; 5%( *#$ %/* (#) %-%.*0$ $%?.*- $## *- $# ,# /+&+%0+ 1&%**.*-2 @%*( 1+#1&+

A$8.*? $## 5):8B )1C'/#*$6 +41+:$.*- $# %//.7+ %$ A:+ $# 1+/'+:$B .*'#/5%$.#*2 =* #)/+ %/+ &):?( .' >+

8%7+ A*#$ $## :/%11(B .*'#/5%$.#* )1C'/#*$2

E)$ = $8.*? 0#5+ 1+#1&+ .* F-.&+ %&0# $8.*? $## &.$$&+ 9%&5#0$ *#$ %$ %&&; )1C'/#*$2 F*,

)0+')& .*'#/5%$.#* #/ ,.0%-/++5+*$0 %/+ *#$ 0)''.:.+*$&( ,.0:)00+,2

G#6 )0+ -##, H),-5+*$ .*


3/28


1. Team building. A set of work or exercises that allows the newly formed Scrum teamto start to think of themselves as a team, do some Forming, Storming, Norming, andotherwise start to become a team. (I do not mean team building in the kumbaya sense; Ilike fighting inside the team about important issues. As you will see.)

2. Realize where they disagree. Often we think people agree what the work or product isall about. In waterfall release planning, we have no means (or only a poor means) toidentify where we disagree. If agile release planning could only identify (better) wherewe disagree, then we all could learn from that.

3. Start to get the whole team on the same page. For example, it might be useful for thewhole team to be, at a working level, on the same page about the product features and theeffort. Such as: the vision, a good-sized feature list, where the business value is highest,what will cost the most to build, etc.

4. Knowledge creation together. By exposing different explicit and tacit knowledge, the

Team can create new knowledge about the business value, the product and the work.This, in my view, is extremely valuable. They can also share, across the team,knowledge that individuals may have.

To the degree one thinks these purposes of Release Planning are important, I think theteam might do Release Planning differently than if one were not trying to go after these

goals. I think #3 and #4 are very important.

!"# '(()"*+, 7 89::*)5

Here's what I think Agile Release Planning should comprise. For a 3-6 month release,most individual teams could do this in about 1-2 days. Maybe 3 days elapsed time, ifthey only do 4 hours a day. With good enough quality to then start sprinting the next day.

Again, we are not done once we have the initial Release Plan. We must do ReleasePlan Refactoring every Sprint. (And possibly some Sprints there are no changes.) Theadaptiveness of agile release planning is probably its most essential aspect.

Perhaps the two most essential ideas behind that are: We dont know everything up-front (by a good margin). Both good change and bad change will happen during our efforts, and our

planning must adapt to those changes. To mitigate the bad changes and tomaximize the value from the good changes (eg, learning).

Again: I do not guarantee that release planning is needed in all situations, nor that thisapproach is needed even with the confined scope mentioned above. In all situations.Still, I have done this now with many many teams, and it seems to have worked with allof them. My experience is that everyone I have done this with has liked it after they did


4/28


it. And thought it was worthwhile. And actually did almost all of it (and almost all that itimplies to me, but is not stated here).

A quick summary of the initial quick agile release planning. We work on the following:

1. Vision2. Product BacklogRolesUser Story Workshop

3. Business ValueBV DriversPriority Poker!BV points

4. EffortDOD (definition of done)Planning Pokers!Story points

5. Risks, Dependencies, Learning, MMFS, Other

_______________________________________ORDER THE WORK

Make scope-date trade-off (Calculate expected velocity)

Calculate the budget for the release (usually a fairly simple calculation)

Determine how to communicate the information to the right people

(Note: MMFS stands for Minimum Marketable Feature Set. See Software by Numbers by

Denne and Cleland-Huang.)

Then we have to talk about some other things [on the board, I usually write OTHER],and see where we go. As one example, sometimes we find that the skill sets needed are

different (now that we see the product or project more clearly).

Then we have to do Release Plan Refactoring every sprint. A typical pattern is to do 3sprints, and then release to the public a much more solid plan. Nonetheless, in everysprint we assume the plan can still be improved. And that doing so is useful compared to

the cost of doing it (relatively low). Until the release is complete.

As I said earlier, the real value in doing this is NOT the 'crappy' estimates that the teamarrives at after the initial release planning. Stated too simply: It is that everyone is now'on the same page' about what the elephant is. At least a whole lot more than we ever hadbefore. And that is tremendously valuable.

Note: If they do really bad or no release planning, I think it increases the chances a lotthat the stories are not small enough. This means that lots of stories just can't get todone, done in the sprint. So, in that and other ways, good release planning is linked to


5/28


having good sprints! Now, this problem (stories too big) can be fixed later, but wow, youwill also have plenty of other problems then. Try to do Scrum as professionally aspossible from the beginning.

* * *

Now I will describe in a practical way, how I have a decent Team work through initialRelease Planning. (Note: This booklet only describes agile release planning for oneteam. Later I may add notes about how to do this in a scaled situation (multiple teams)).

;/%/"3

The first step is Vision. We define the vision, and make sure that all the right people seethe same vision and agree with it. Or at least start to align with it.

Who: The full Scrum team and the business stakeholders should do this together. TheScrum Team includes of course: the implementors, the ScrumMaster, and the ProductOwner.

The business stakeholders (BSHs) are the other key people associated with the team thatprovide key input about what the product should be. (Note: BSH is not a defined Scrumrole. It is a concept that I use to refer to a small set of people outside the Scrum Team .)

I usually think of the BSHs as being 4 people, but of course the number can vary. If theScrum Team is 7 and the BSHs are 4, we already have 11 people in the release planningmeeting(s). Starting to be a big group. As the group gets bigger, this makes good

communication harder.

The BSHs may be customers or internal managers, or really anyone who will participateenough to provide valuable input. It is mainly the Product Owner's job, in my view, tomake sure these are the best possible people, given the specific situation. Often theProduct Owner must seek help in selecting the BSHs.

In my experience, the BSHs are never perfect representatives of 'the customers' of theproduct. Sometimes the level of imperfection is quite impressive. Sometimes, once the

imperfection is identified and made visible, it can be corrected.

Typically the BSHs represent two main groups: (a) 'the customers', meaning usually ormostly the external and/or internal end-users, and (b) the firm, usually personified as the

widows and orphans who ultimately own all the shares of the firm.

What: By vision we mean some relatively short statement of what the product will be,once completed. What it will be, and why we or the customers will be excited about it.And a few more scoping details.


6/28


It establishes the 'north star' of our direction. It hints at what business value is.

And it is like an elevator statement. Something short that you could explain in 2 minutesto your bosses' boss.

We particularly like this format, which comes from Geoffrey Moore's book, Crossing theChasm: For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)

In addition to these nice words, we also strongly recommend you find one or two keynumbers to ground the vision. The numbers make the vision more real. The words are

usually quite sweet, while the numbers make it real (either bigger or smaller than theythought from the words only). The metric makes the words more tangible.

Examples: "We expect to make $3 million in the first year." "Widget production will go

up about 125%." Whatever metric (or two) makes sense.

Why:- To clarify where we are going. Yogi Berra: "You have to be very careful if you don'tknow where you're going, because you might not get there."- To motivate all parties. This is quite important.- To set a direction and a rough scope. ("This is about the iPad-1, not the iPhone, nor any

other iOS gadgets.")- To start to get everyone on one page. My experience is that this is very hard. They tendto want to be on different pages, it seems.

How: We find this typically takes about 1 hour. Sometimes less, sometimes more. Wefind it is useful to do 15 minute timeboxes, to check if there is too much aimless orcircular talk. To check for those talking too much, and those talking too little.

We recommend that the 'smart guys' (those who think they already know the vision) talk,and the dumb people (typically, the implementers, who usually are just learning thevision) actually physically write the vision. This helps assure that the implementers 'get

it'. Sometimes, sooner or later, the Product Owner, who may be better with words, mustimprove the wording.

Remember that perhaps the most important goal is not to have knowledge (in one

person's head) but to spread the knowledge into the heads of all the right people.

Ending: Usually the team forgets to identify a key metric. Go back and do that. Then,ask the whole team for the thumb metric. Say to them: "If the thumb is pointing


7/28


straight down, this is the worst project you have ever been on. If the thumb is pointingstraight up, this is the best project ever. Half-way, this is just an average, typical projectaround here. So, one-two-three, show your thumb metric..."

Then the Product Owner should lead a discussion of the results. Sometimes this means

improving the Vision statement. Also, some people are by nature skeptical at this stage,and we just learn that. Sometimes it is just a short discussion.

Roles: The Product Owner is leading the content. The ScrumMaster is leading thefacilitation. The SM checks the time boxes, and tries to assure that everyone talks theright amount. The Product Owner is always assessing: have we said the right things sothat the group is motivated?

Later: The war is not won or lost in the first hour of battle. The Vision is a start.Hopefully a good start. But some projects can start with a great vision and then getbogged down nonetheless. Some projects start with a clearer vision, some with a less

clear one.

The Vision is typically improved later on, in any case. For those who may beuncomfortable moving on, remind them of this.

2)"0".

After we complete the Vision, we must develop the Product Backlog.There are two parts to this.

First, we must define the Roles to use in the User Stories.Second, we must write User Stories. I call this second part a User Story Workshop.

(If your team prefers to use something else than User Stories to generate the ProductBacklog Items, then the wording of this section would be changed a fair amount. But Ithink most of the key ideas still apply. All my teams have found pretty good success with

the User Story format.)

Let's break this down.

Assumption: We have a new team that is doing Agile-Scrum for the first time.

Who: We want the whole team of pigs (PO, SM, and implementers).

And the BSHs (business stakeholders). Usually you want the 3-5 best businessstakeholders you can get. They are never perfect, but at least they are the best you canget. The Product Owner is usually the main person driving which BSHs to bring in.

The Product Owner is leading the content. The ScrumMaster is leading the facilitation.


8/28


What: We want about 5 to 7 roles. These are the roles to go in the User Stories. (Not theroles in the Scrum team.)

And then we often want about six months of work for some good release planning. (In

some situations, we want more or less work.)

If we have about 6 months of work, lets do some math. My rule of thumb is 8 stories per2 week Sprint. 6 months work is 13 sprints. 13 x 8 = 104. Now, those 104 stories are allsmall enough for a Sprint. So, in initial Release Planning, we can be pretty happy withsomewhat less granularity. So 50 stories would be good (average about twice as big as aSprint-sized story). So, this gives us a rough idea of what we are shooting for. Of

course, we will learn a lot later, and can make many adjustments.

So, we only need about 50 stories that cover about 6 months worth of work.

If we ask the group (the Scrum Team and BSHs) to produce 50 stories, and they onlyproduce 42, we are probably still at a good level of granularity for initial releaseplanning. But, if we only ask them for 42, then often they will only produce 32 which

is not enough granularity.

Now, if you already know the work is more or less than 6 months (for one Team), thenyou have to adjust this ballpark number (adjust the 50 up or down).

How: Brainstorming to get 5-7 roles can be easy or can be hard.

We mostly want different user personas (roles), end users of the system or product. But

more generally, we want any role that would want some feature in the product. Even ifthey don't (directly) use the product.

(Again: These are not the roles of the Scrum team members. A fairly common question.)

Some teams will come up with 30 roles. Some will come up with only 2. We want toeither synthesize or break down until the number of roles gets in the 5-7 range.Something magic about that number. But not worth dying for. If they only have 4 roles,things will probably still be ok.

Whatever they do, it will probably work the first time. But it will become better as they

start to get practice with stories, and appreciate, tacitly, the characteristics of a goodstory.

OK. Now, with the Roles, the whole team starts to write stories. We let them self-organize. We give them 15 minute timeboxes. At each 15 minute break, they "checkin." They inspect progress and see if they want to adjust anything. Usually they see thatthey want to write stories faster.


9/28


Typical productivity for a team is to average about 1 story per minute. So, in about 50minutes.....50 stories. If your team is faster or slower, is it usually not a big deal. But thatgives you a ballpark.

When they feel finished, we recommend having the whole team gather around all the

stories (imagine them on a wall). They should look at them, and try to see what needsimproving the most. Maybe a few aren't worded well. Maybe a few need the INVEST

criteria a bit tighter. Maybe two team members identify 3 missing stories.

What were the INVEST criteria?* Independent (we try to maximize this, but we never can make all stories independent)

* Negotiable* Valuable* Estimable (clear enough that we feel effort can be estimated)* Sized Appropriately* Testable

It is sometimes useful to get more sophisticated. I don't like to do that the first time.They need to get one cycle of just doing the basics. Probably several cycles.

We recommend that the PO answer questions and talk about the product that heenvisions. But let the others identify the specific stories. He gets them more engaged.They get more creative. They have better motivation.The PO can always add or modify

later (if there work is imperfect).

Why?

Why do we have all the pigs and the business stakeholders?Several reasons I will mention.

1. We want the whole group to share whatever tacit knowledge they have with the rest ofthe group.

It turns out that everyone has some knowledge or ideas to share. Or at least some good

questions. Well, almost everyone (yes, there are a few exceptions sometimes on this one.)

2. We want the group to create knowledge together. And share it together.

A bunch of things happen has they create knowledge. One is that they all start to form asimilar mental picture (or pictures) of the product and the effort and things related to it(eg, the architecture).

3. We want the team to develop motivation together.

Finally, having been involved in the creation, the whole thing becomes their 'baby.' Thisis far better motivation than we get from 'the mushroom treatment,' which is de facto the


10/28


most common thing. (The mushroom treatment is where the team is kept in the dark andfed manure -- this is great for growing mushrooms, not so great for growing teams.)

Yes, it is somewhat expensive to have everyone involved. But the payback during the

project is very high. Very high. And the time to market is better.

Time Box: As indicated, I like to have a series of 15 minute timeboxes, where the teamchecks in. Are we going too fast or too slow? Anything we should change? Who istalking too much, who too little?

Usually the whole thing can be done is 60-90 minutes. But really it is not a problem if itgoes 120 minutes. Or even more. The main thing is, as SM, if one guy gets talking andworrying, and nothing is getting done, you can't let the team just spin. Someone must fixit, and get them productive again.

Common Issues: I like brainstorming rules. Meaning: Anyone can create anything, and

for this timebox (say, 15 mintes), no critique is allowed. Then an editing or 'fixing'timebox, where the team reviews and improves the roles or stories. Then another 'createanything' timebox. And so on.

I find creating one story and then criticizing each one is too slow, and inhibits the team

too much. Especially beginning teams.

Another issue is having only one person write the stories. If a team really wants to dothis, it is not terrible. But things usually go faster if everyone writes.

Not sharing. I think it is useful if, as a person writes a story, he shares it with the group

(says the words of the story out loud). That way, no one writes the same story a secondtime.

Top Down/Bottom Up. I find some people are top down thinkers and other are bottomup thinkers. It takes both kinds. Let them be who they are. Especially while they create.Rather obviously, top down thinkers will tend to write epics that need to be broken down(even at this point we can often see some epics are just too big). And bottom up guyswill write stories that sometimes are too small. And we sooner or later need to combinestories.

User Story format. I like it and encourage it. They especially tend to forget the "so that"

clause. So I encourage them to include it. But, if they just can't think of the feature in auser story format, I say: ok, just write something as a PBI (product backlog item). Maybelater we will convert that into user story format. Be easy on the beginners. They are just

learning to ride the bike.

Results. Usually the team ends up with 40-60 stories that represent 5-7 months worth ofwork. Ballpark. (It is just a gut feel at this point.) Which is a great start for the ReleasePlanning.


11/28


These user stories (or PBIs) are just the right middle level of 'features' for everyone tohave a clear enough picture of what the product will be. It embodies the vision. It makesthings concrete for people, without getting mired in details. Wonderful. And they can dothis the first time.

Is it perfect? No. Could it ever be perfect? No. Is it a reasonable time to spend to get alevel of 'quality' (in all aspects) that it very useful? Yes!

Can we write more stories, if we discover them, later in Release Planning? Yes! And italways happens! And will we add more stories as we are doing the Sprint? Yes, always.

=9%/3#%% ;*09#

Now we move on to Business Value in Release Planning.

Per Yogi Berra: "You have to be very careful if you don't know where you're going,

because you might not get there."

If you are in the mood, this can be very funny. Or just a chuckle. But this is ourproblem. How do we identify what the customer really really wants. Well, businessvalue is part of that.

When we did the vision, we directly or indirectly probably talk ed about business value.

Now we want to talk about business value for each individual PBI (product backlog item)or user story.

Again, we want to have two actions within this.

People: Again, to do this work, I want the whole team of pigs (PO, SM, implementers)and the BSHs (business stakeholders). Again, the BSHs are the best people we can get toattend Release Planning to represent the customers and the firm well.

Business Drivers:

It is my contention that the key thoughts and phrases we want to use about business valuevary by the situation. The product, the customers, the people involved. It may be that thehigh-level basics of business value for all for-profit firms could be distilled into 5phrases. But I find for useful discussions in specific products, it helps to 'invent' the 3-7

top drivers each time.

Business drivers may include making money, risk, customer satisfaction and lots of otherthings. Or not.


12/28


So, they whole group gets together and discusses and agrees on the top 5 (about) businessdrivers that apply to the set of work (the product) as represented in the existing ProductBacklog (its PBIs). Sometimes this will lead to the identification of some new stories (orPBIs).

Priority Poker:Most of you are familiar with Planning Poker, which is where we use the planning pokercards to vote as a team on the relative story points of [new story] compared to the 1 SP onthe [reference story].

Priority Poker is very similar to Planning Poker, except that it is about business value, noteffort. In fact, we assume there is no correlation between effort and value.

So, the similarities: use a team, vote, use Fibonacci cards, discuss assumptions, shareknowledge and ideas, average the numbers after reaching some consensus, the number is

comparative, relatively quick, somewhat imprecise for each individual card but fairlyaccurate over a set of cards, etc.

Some differences: a different team (the experts on business value), reference story is theTOP story (for business value) rather than the SMALLEST story (for effort), prefer the

real Fibonacci sequence at the top end, done in the presence of the implementers, etc.

So, first the top experts (usually between 4 and 7 people) on business value huddlearound the user stories (or PBIs) and determine which one has the most business value.This one is arbitrarily given a value of 90 or 100 (it is minor which one you choose).

The Business Value experts are typically the PO, the BSHs and maybe one member ofthe Team who has a lot of experience with customers. Or for some other reason, knowsBV pretty well.

OK, now we have the reference story for Business Value. Then the BV experts start toadd relative BVP (business value points) to each user story (or PBI).

Here are the rules:* pick a story randomly (we do not want to prejudice the panel by already putting storiesin BV order).

* discuss the story* identify drivers of BV for that story (but not how much the driver is affected)* ask each person to pick a Fibonacci card, but don't reveal the vote to anyone* once everyone has selected a card, 1-2-3, they all reveal the card* the people with the two extreme cards discuss why each was high or low* the team re-votes until within 3 consecutive Fibonacci cards of each other* then the averages the numbers, to the nearest integer.


13/28


Example: The vote is 34, 55, 55, 89. The value for that story is 58.

Meaning: If the reference story is 100, and they vote 50, that means that they feel that thenew story has 1/2 the business value of the reference story, considering all the different

drivers of business value.

The others listening (the non-voters) may ask questions at the end of each "card." Thepurpose for them being there is so they can pick up the tacit knowledge about businessvalue, and which stories are more important (and why).

Final review: Once all the cards have been assigned BVP (business value points), theexperts then gather around all the cards on the wall, and look for "the stupidest" numbers.Often in 50 cards, they will identify 3 or 4 that seem stupid now. Maybe this 30 seems alot bigger than the other 30's. Maybe that 70 seems too high now. The personidentifying can ask the experts to re-vote. In general, we would expect them to re-vote ona few. After all, now that they have discussed them all, they are probably smarter now

about business value than when they started.

Timing: Priority Poker takes some time, but is worth it. Understanding Business Value isvery, well, valuable. Of course, one person in your group may talk too much. So, thefacilitator must monitor that.

We find a time box of 1.5 to 3 hours is usually quite sufficient for 50 cards. But again, ifthe discussion is deemed valuable by most of the participants, it is unlikely that 4 hours

would be too long.

Comments:

We like them to think more and more that no two things have exactly the same businessvalue. Yes, for example, we may have to do 5 steps in a business process, but steps 2 and5 are exciting. The others are just chores that must happen. Steps 2 and 5, when wedeliver them to the business and deliver them well, that's when the big smiles come out.Or that's when the big money is made.

Often new stories are identified. Or a few existing stories are deemed so big, that theymust be sliced and diced into smaller stories. This is normal.

Sometimes an expert may feel he does not know how to vote on a specific story. Heshould take his best guess anyway. And learn from how the others vote.

Averaging: Apparently there are many who have been taught Planning Poker and told toforce the team to consensus on one Fibonacci card. This is incorrect for Planning Poker.The research shows that averaging is more accurate and faster. (If not too fast.) And thesame applies to Priority Poker.

Accuracy: Are all the cards perfectly accurately assigned BVP? No!


14/28


Have we learned a lot more about our different ideas about business value and shared thatthroughout the group? Yes!Did the numbers help? Yes!Can we change the BVPs later, once someone becomes 'sure' that one or more is wrong?

Of course, by team vote.

Will we change some? I absolutely expect it. We want you to get smarter and smarterabout business value, in multiple ways. This should in part be reflected in changes to theBV points.

Epics: If an epic is worth 100 BVP, does that mean that when it is broken into 5 stories,then each of the 5 is worth 20 BVP? No, we don't assume that. In fact, along with Pareto,we assume that there are more vital parts of the 100 story, as well as less vital parts. Inthe simplest world, one of the smaller stories would be worth 80 BVP and the other 4stories would total 20 BVP together (the 80-20 rules). But life is not always that simple,either.

Results: One clear result is that we have a BVP number on every PBI (or user story).This is remarkable. And no one in the group thinks any of the numbers totally suck.

More importantly (IMHO), the whole team starts to share a bunch of ideas about how the

BV is distributed amongst the features. Every feature is not equal. This is a great thing.

Typically new stories are identified. And typically the MMFS (minimum marketablefeature set) is starting to emerge.

But the main thing, to me, is that the whole group starts to share relatively specific tacit

knowledge about the relative business value of each story. Specific down to the userstory. Not hand waving at the vision level.

This work changes motivation. And it changes the behavior. Of everyone. The businessguys start to respect that the geeks understand them a little. And the geeks nowunderstand better why business-side work is so hard.

***The real value of all this work is getting closer. And will be revealed soon. Just a fewmore steps....

?@@")- 7 A

Now we move on to Effort in Release Planning.

Estimating the effort of a Release Plan is not quite what I wanted to do in this part. What

I want to do is estimate the relative effort of each User Story that we have so far.


15/28


So, imagine that we have 50 user stories representing roughly (per gut check) about 6months worth. Ballpark.

Now we have to do two things:

* Establish a Definition of Done for the Team.* Do Planning Poker, which estimates a "story point" number for each user story.

Definition of Done

Stealing from Taiichi Ohno, I suggest we do this differently than I see many people do.

What others do is a list that describes what 'done, done' means once we get there.

Maybe they say:* Coded

* United Tested* Basic documentation written and reviewed* Functionally tested

* Small regression test* No bugs (all identified bugs fixed)* Product Owner Review (any issues fixed)* No increased technical debt* Promoted to the QA2 Server

What I would prefer is greater clarity how we got to this state. Or even if we really can

get to this state.

What Taiichi Ohno proposed is that we ask the workers to write down the process thatthey currently use.

Once the workers do that, they themselves can see that it has weaknesses. And once theprocess is (more) visible, then everyone can help improve it. But especially the workersthemselves will improve it. And so, they start to 'own' the process. Which makes forbetter motivation. And better results.

Some in agile are concerned. Their concern is that, by writing down the process, we havelocked the process in stone. And have made people into machines.

And this is actually the opposite of what we are doing. We are making the processvisible so that it can be improved. So that it can be changed. NOT so it will remain thesame. Now, by making the process visible, we do enable anyone who sees the process toopen his mouth. And if the Team is not strong enough, then a 'bad' manager could try to

force them into his process. But this seems unduly negative in the general case.

Let's make our suggestion more concrete.


16/28


[Insert picture of sample DOD.]

So, before or during the Sprint Planning Meeting, the team can do many things to 'get thestories ready, ready'. But what we want to estimate in story points are the things that

happen during the Sprint.

We recommend that the first thing done in the Sprint is that we have a conversation aboutStory 1. The conversation, in classic form, is between the PO, the Coder, and the Tester.(Technically, with all the people with all the skill sets to get that story done, done.) Inthis (short) conversation, all 3 people try to assure they are on the same page about thestory.

Then we list everything that the Team says it can and will do to get Story 1 to a done inthe Sprint.

In my opinion, the last step (or near the last) must be PO Review, meaning that the POlooks at the working product and gives feedback. If the PO feels the customer will notlike it, he gives that feedback and the implementers must fix it. In the Sprint, in my

opinion.

And anything done after the Sprint to make that story into something that can go in thelive production product, all that work is listed as well. Below the line. And it represents,in my opinion, all the bad news getting better with age. But we have to accept that wecan't always get to "live, in production, in use by the customer" within the Sprint.

We think this approach to DOD gives much more clarity or transparency.

And starts the Team on the road to becoming more professional. And enables the Team toimprove their own process.

20*33/3. 2">#)

Now we come to the point of describing Planning Poker. This is a continuation of thediscussion of Effort.

Planning Poker has been described before in the Agile-sphere, so we will be brief. It isdescribed at greater length many other places.

***Some basic characteristics:


17/28


We find the 5 best people to vote on effort for this work. (About 5; maybe 3-7.) Inpractice this means the Implementers in the Team. Often to call them individuallyexperts in estimating effort isa stretch. But the idea is that they are the best expertswe can find. And in practice, with maybe a bit of time, they typically are the most expert

at estimating the effort for the work of this team.

Usually the Business Stakeholders (as I call them) will not stay around for this work.This is ok. Not ideal, but ok. We will bring them back in later.We use the planning poker cards with the Fibonacci scale.The approach is wide-band delphi. Delphi means we use the best experts we can find.Wide-band means that we allow the experts to talk and learn from each other. This bears

strong resemblance to the knowledge creation ideas from Takeuchi and Nonaka.

The basic technique

We have about 5 experts.

We use the people in the team who will be building the product. The affects motivation.This affects their knowledge. This will affect their later behavior. We try hard to get allof them, so that none of them feels left out.

The Product Owner is typically not one of the voters, but he/she is there. The PO has tomake sure that the team is understanding each story correctly. Typically the PO is abusiness person and in any case is representing the Firm and the Customers. So, whenthose kinds of questions come up, he must be there to give them the best possible

assumptions to work with.

The ScrumMaster (SM) is there to facilitate the meeting or the work. Ex: To try to getthe quiet ones to talk more and the talkative ones to talk less.

In this discussion, we will assume all the PBIs (Product Backlog Items) are in the UserStory format, so we will call them stories.

The Experts must now choose the reference story.

Imagine that the team has 50 stories in the Product Backlog, covering about 6 monthsworth of work. The Experts choose from that set the smallest story. Well, except that it

should not be too small. Ideally it is about 1 ideal person day (after adding together all theideal hours from all the required skill sets). [Someone should check that the story isabout the right size. But don't tell anyone, and especially don't let the experts startthinking in units of time (days, hours). Still, if the story is too big or too small, it starts todistort the voting, in my experience.]

The reference story is arbitrarily given a 1. Meaning, it has an effort value of 1 StoryPoint.


18/28


Note: An earlier section talked about how the Team must have a strong DOD (definitionof done). The DOD should make clear what things are being done in the Sprint to get thestory 'done, done' as we often say. So, it is the effort of 'these things' done during theSpring that we are estimating. Earlier we talked about a minimal DOD.

OK, now the team estimates the relative size of all the other stories in comparison to thisreference story. This happens in this way:Select the (next) highest value story.Discuss it briefly to assure everyone understands it the same way. PO describes story.Experts ask him questions.

Someone asks "any more questions?" If no....Each Expert privately selects a Planning Poker card that best represents his feeling ofhow much bigger the new story is in comparison to the reference story. For example, if 7times bigger, the choice is between a 5 card or an 8 card. Likely, the 8 card will bechosen...

If all Experts are within 3 consecutive cards of each other (ex: all have either a 5, 8 or13), then average the numbers. Example: 5, 5, 5, 8, 13 .... averages to 7. The average is

rounded to the nearest integer.If the Experts' votes are more dispersed (ex: 3, 5, 8, 13, 20), then the two extremes talk(mostly). In this example, the person with the 3 and the person with the 20 both talkabout their assumptions, etc. If the assumptions are business-related, then the PO candecide which assumption is correct.With the new information, each Expert votes privately again.Voting and discussing can go on a couple of rounds. Almost always, the final answer fora card is the average after the Experts get within 3 consecutive cards of each other (Ex:

votes are 2, 3, or 5).

If, after X number of rounds, the Experts have not reached some degree of consensus(with 3 cards), then the team should just take the average. Each team can decide how big

X should be. My guess is 4.

Once the number is decided, it is written on the card (story) in such a way that everyoneknows that it represents the story points (color and placement on the card usually makethat clear).

A few additional comments:

The discussion is actually the most valuable thing. The numbers drive a betterconversation about the more important stuff.Sometimes important assumptions are identified. In that case, the assumption shouldprobably be recorded (eg, on the back of the card?). Later, if we discover that the

assumption is incorrect, we can refactor the story points for the related stories.


19/28


Sometimes the Experts will want to address certain general issues. The issues might bearchitecture or design related. This is where the SM has to use good judgment. Typicallylet them discuss for 'a while' but not too long. Maybe make one or two drawings. Makeand document a few assumptions, and then get back to Planning Poker. Sometimes oneor two people on the team want to discuss these issues too long. In this case, the SM must

use good judgement and get the Experts back to Planning Poker.

You will hear of people suggesting that the Experts must agree on 1 Fibonacci number(eg, 8) for a given story. This is _not_ recommended. First, it gives a strong incentivefor people to too quickly start to shade their numbers, rather than vote what they reallythink. They find that George, the senior guy, is stubborn, and to avoid conflict and tokeep things going, they decide, almost subconsciously, to start voting a closely to whatGeorge says as fast as they can. The research shows that the average is more likely to bethe correct estimate. And it actually takes less time to reach that number (if everyone isvoting honestly).

Usually one or two new stories are identified while we are doing planning poker. This isnormal. Occasionally it turns out to be the most important story.

At the end

It usually takes no more than 1.5 hours to estimate 50 cards well. The first few cards takelonger. Then things speed up. On average; sometimes one or two later cards will takesome time.

Once all the cards have been estimated (for effort), all the cards should be put on thewall. And then the whole Team should gather around. And see if they can identify one or

two 'stupid' cards.

It is very common that 2 or 3 stories that were estimated early on will need to be re-estimated, in the team's opinion. This is fine, good even. And normal. They now, as ateam, are much smarter than when they started Planning Poker.

Cost-benefit analysis

Now one or two people in the team calculate the R ratio for each story. BVP divided bySP. For each story. The R should not be more than one decimal place. This gives:the low hanging fruit

the bang for the buckthe return on investment...however you want to put it.

We next suggest that the PO organize the story cards based on the R number. Highest R

first. Lowest R last.


20/28


We ask them: What do you think? Is this the right way to do the work? Often they say:Well, it is a good start but we need to make some changes. Which is 99% of the time, theright answer in my opinion.

What ideas do we use to re-order the work? More on that in the next section.

1/%>%B C#(#3


21/28


Learning. In Agile we recognize the importance of learning. We need to learn what thecustomers really want. We need to learn some technical things to become more effective.These can be good reasons to change the order of the work.

MMFS. Minimum market feature set. This phrase is from Software By Numbers by

Mark Denne and Jane Cleland-Huang. The idea is that there is some minimal set offeatures that must be put together before a customer can realize the value of the wholeset. Sometimes this minimum is quite small, quite small indeed. In other circumstancesit is much larger. In general, too many of us (producers and customers) have beenbrainwashed into believing the 100%-100% rule, so that we think the MMFS is muchlarger than it really is. In any case, low value features sometimes must be moved up, inorder to add the 'missing something' to make the next release truly 'usable'.

Other. This is a catchall for all the other reasons we have to change the order of the userstories. My favorite example is this: A committee is going to me in 3 weeks to decide onthe funding for our project. George is on the committee. In our opinion as PO and in the

opinion of everyone else, George is much too excited about user story 87, whichcurrently would not be built until the third release, and that is assuming no new userstories get identified, which is very very unlikely. But, George is on the committee. Anduser story 87 is only 5 story points (our velocity is 25). So, we ask the Team to go aheadand get the story done in the next Sprint so that George helps assure that the project getsfurther funding. Not rational, not 'the right thing to do', but sometimes you have to dealwith real people and irrational things have to happen.

In our experience, Risks and Learning should be used more often to re-order the productbacklog. And Dependencies less often. But in any case, using the R factor solely isalmost never the right answer.

How to do this

We recommend that the product backlog already be ordered by the R factor. (The Rfactor was discussed in the previous section.)

We recommend that the whole Team be there (PO, SM and implementers) and thebusiness stakeholders.

Then, anyone in the group can start to suggest re-ordering the product backlog based onany of the ideas above. Any move has to be explained to the whole group. If there are

disagreements, the PO makes the final decision.

Again, let me emphasize that sharing knowledge with the whole team is at least asimportant as any other outcome we are trying to achieve. So, doing this without the

Team is not recommended.


22/28


Normally this does not take very long. Again, 6 months of work for one team is typicallyexpressed as about 50 user stories. So, re-ordering 50 user stories, where most do notmove, does not take long.

H":(0#-/3. -,# 20*3

As discussed in the previous section, the user stories are now ordered.

Now we must complete the Release Plan.

So, we must make the trade-off between scope and date.

There are three ways to do this:

1. Fixed Release Date. We will release every X months or Y sprints.

Some teams or firms prefer to have a fixed release date. It makes things simple. It makesmanagers and others realize that we will release. They only question is exactly what willbe in the release.

2. Fixed scope. We will release when all of the scope (all the stories or PBIs in that

scope) is/are done.

3. Trade-off. We understand our velocity and go down the Product Backlog a ways. Andask: two sprints, umm, how many features are done? Ok, three sprints, how manyfeatures are done. Ok, four sprints, umm, customers would really like to see another

release, the market needs it, but do we have enough? Ok, five sprints, umm, I think wehave enough. Let's shoot for that. -- It is that kind of trade-off.

This requires that we know our velocity.

Estimating Velocity

With an existing team, you might already know their velocity. With a new team, youmust guess.

So, we do a calculation to get an educated guess.

First, for the 1 story point reference story (for effort)... how many ideal person dayswould it take. The Team huddles around the story and reaches a decision. Imagine the

number is 1 SP = 1.5 ideal days.

Imagine the Team has 6 doers (of real work).

Imagine the Team will do 2 week Sprints.


23/28


24/28


Communicating the Plan

I tend to put pressure on new Product Owners to release earlier. They are mentally tootied to the concept of the 100% - 100% rule. That nothing can be released until

everything is done. This is almost always just wrong. Hence, I always ask for an earlierrelease.

Once the PO and Team agree on the scope and date, we then have to talk about the

"communications plan", as I call it.

If the Team works with a manager who truly understands adaptive planning (meaningthat the current plan will be revised and improved every sprint... this is only the firstguess at the plan)... then tell that manager the truth. Here's what we guess, this is whatwe are worried about. This is our feeling about how it is likely to change. And maybewe have contradictory feelings.

But often some key managers do NOT understand adaptive planning. These "tough"managers (or customers) want you to give a fixed date, and then deliver to that date.

Then you are stuck. So, we have to do what we used to do in waterfall. Add some"buffers" (aka padding, etc, etc) to the date. For "problems", for new stories to beidentified later, etc, etc.

It is hard to guess how much buffer to add. We have no additional magic.

But, we do strongly suggest that you protect yourself and your Team. Do not get them in

a situation of a Death March, trying to meet an impossible date. More about this later....

And then we talk about, "ok, how will we communicate the date?" (Almost always, thekey issue is the date.) You have to start setting expectations that the date will change ifother things change (substantially), and they are likely to change substantially. This isnot one conversation by the PO, but a series of conversations by and with many people.It is over time that the start to see and feel the power of adaptive planning.

For some of you, the issue is not so much "communications plan", but "what do we put inthe contract". But contract issues are too many to cover here.

Finalizing the Plan

Assuming you have "business stakeholders" as I described them earlier, then always youhave to review the release plan you have with them. Get their buy-in or comments or

adjustments. This of course may affect the communications plan.


25/28


The Plan in some sense is never final. In another sense, depending on what you say towhom, it will be perceived as final. You must use common-sense.

So, this is most of the basics. A bunch of issues we have not addressed. Some I will

address in the next section.

1#@*+-")/3. -,# 1#0#*%# 20*3

Now we had completed the initial release plan. (See above.)

What were the key outcomes?

Well, the plan has now some sort of scope, date and budget. Usually on Day Zero thequality is 'crappy' to use the technical term. As it must be, given how much we don't

know on Day Zero.

We have also set up what I call the early warning system. By this I mean we have thebasic release planning information put together in such a way that it is easy to refactor therelease plan. Or at least, much easier to change than when I used to update the MicrosoftProject release plan (wow, was that hard). And we can track against the (refactored)release plan, and give ourselves (as a Team) an early warning if we start to get intotrouble.

Now, the real win was that we now have 'everyone' on the same page, at a useful middlelevel of detail: what is this elephant? What work are we about to do.

The real win is the broader Team knowledge creation. The real win is that the explicitand tacit knowledge has been exchanged and shared, and new knowledge has been

created.

And then we start the first sprint. Or more specifically, we start the first Sprint Planning

Meeting.

So, in some sense, release planning does not end. We only now begin RPR (release planrefactoring).

It is absolutely fundamental to agile release planning that we refactor the release planfrequently. I say (and many others say) that we must refactor the release plan everysprint. Every sprint. Ok, maybe during every 10th sprint there will be so little change,that we don't have to change the release plan at all. Ok, maybe this very occasionally

happens. But at least we must evaluate that that is the case.

Now, when I say release plan refactoring, I mean all of the following:


26/28


* changing the vision (all of these items are 'if needed' only)* improving the product backlog items (more, fewer, smaller, better)* re-evaluating business value (very key and very hard)* Re-estimating the effort (eg, where Story Points are wrong, for new stories, for newly

sliced stories, etc.)

* taking a new look at the benefit-cost ratios* including new learning about risks, dependencies, learning, MMFS, etc.* re-ordering the work* doing a new scope-date trade-off. Usually to make the initial release smaller (feweraggregate story points -- is one way of expressing it).* including the newest velocity expectations (based on recent trends).* adjusting the buffers and communicating the new, new release plan (scope, date,budget) to the right people

Now, I also include in Release Plan Refactoring all the changes to the Product Backloginformation to make it ready for the Team to be successful in doing the Sprint work.

Some people use phrases such as 'product backlog grooming' for this. (Note: I think'product backlog grooming' can have other meanings too, depending on who is using the

phrase.)

These activities include:* breaking down stories or epics into small sprint-sized stories.

* improving the stories or PBIs (wording, INVEST criteria, etc.)* estimating the business value of the smaller stories* estimating the effort of the smaller stories* answering questions from the Team about the expected sprint stories* adding detail (notes, acceptance criteria, etc.)

* adding an agile spec for each PBI to be in the next sprint. [Sometimes this may be done2 sprints or more ahead. But not 'way' ahead.]* checking that the Team thinks each story (likely to go in the next sprint) is 'ready'before the Sprint Planning Meeting

One could argue that release plan refactoring and product backlog grooming arecompletely different. I think this way of thinking is unhelpful. One of the purposes ofrelease planning is to make the work in the sprints more successful. Release planning isnot completed until, for each sprint planning meeting, we have 'the stuff' ready for asuccessful sprint planning meeting. Among the key success criteria of that meeting is: we

used the time of the business stakeholders well.

Let me pause.

Why is using the time of the business stakeholders important?

Well, they are the key independent check on the thinking of the Product Owner. Weknow from long experience in our industry that 'knowing what the customer wants' isextremely hard. Extremely. The business stakeholders are people whose time is scarce


27/28


and yet these people are essential to us in getting a much better fix on what the customerreally wants (or what the firm wants). We want them in the Sprint Planning Meeting,agreeing with what the Team takes in and, at the Sprint Review, giving us feedback.Because these independent input and output checks are so vital, we must use their timeefficiently.

Thus, for me it is better to think of higher level release plan refactoring and lower levelrelease plan refactoring. And when people say 'product backlog grooming' they oftenmean lower level release plan refactoring of those stories about to go into the next sprint.

Again, the key idea here is that we ALWAYS refactor the release plan every sprint. Weimprove it. This is absolutely key to adaptive planning.

89..#%-#


28/28

FAQ

1. What do you recommend for multiple teams, in a scaling situation? A: Well, for now,

I am not trying to discuss that here. Please contact me to discuss. It needs more than 20pages.

2. Where is your scientific proof that this is the best method? A: In general, as an overallapproach, it is heuristic. I dont think any detailed approach has been scientificallyproven. However, there has been significant study on parts of the approach (and onalternatives). I will try to write another paper soon that reviews that information.

I think these methods are against some proven methods. But this approach has differentgoals than the proven methods have or had. For example, estimating might be moreaccurate another way than planning poker, but I think the knowledge creation is better

with planning poker, and that is my main goal.

3. What about use cases? A: I generally like light-weight use cases. In general I have notfound them necessary when doing the initial release planning. But often extremely usefullater (for the implementers and others in doing their work). I do think that the issues thatuse cases address will come up in estimating effort (and in other places), and this shouldbe discussed (and maybe documented) just enough at that time, so that release planningmay proceed.

4. How about more discussion of the theories behind release planning? A: Well, I dodiscuss the ideas quite a bit, and I do feel that the goals I have for release planning are

different than what many people have had. But I wanted to keep this booklet short. I willtry soon to write another booklet about that. I thought it would be more useful to manypeople to describe the practical application. Some people see better when you talkpractical details.

5. Do you think user story cards are sufficient? A: Umm. Hard question. I think usually,a Team can do decent initial release planning with only story cards. Almost always theydiscuss some other issues along the way. Those important details should be documentedin some way. But those details are never all the details that the implementers will need.In doing Sprints worth of work, I recommend the Agile Spec idea; just enough, just intime documentation. Of the requirements is saying it too quickly, but gives you the

basic idea. In any case, not my main subject.

6. There are lots of special cases. You did not deal with them. Why? A: A wish todiscuss things quickly.

joe’s approach to agile release planning v1-06

Documents