Joe's Approach To Agile Release Planning V1-06

Joes
Approach to Agile Release Planning

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 that
every Sprint we refactor (as much as needed) the release plan to reflect all the new
information.
***
This booklet is for beginner to intermediate teams. In typical situations. Your mileage
may 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 plan
that should happen every Sprint. Some changes will be minor and some major. But it is
essential 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 only
one 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 it
is for about 6 months worth of work for one team. (6 months worth of work is fairly
arbitrary, 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; it
will never be perfect.
Note: Despite not believing in the initial plan, sometimes we are forced by
circumstances 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 are
risky business decisions made with too little information. As most business decisions
are. If done with equal professionalism, I do think the risk is somewhat reduced
compared to a similar waterfall plan.
***
Here are some values, principles and practices around agile release planning that I have
taught to numerous teams. In general, the teams have found them very useful. While you
Saved on 1/5/13 8:50 AM Page 1 of 28
Ver 1.06 copyright 2013 Joseph H. Little

may not find all of them useful, we hope at least they will make you think. And at least
that thinking will make your results better.
Warnings
Not all of you need to do agile release planning. For example, if you release every
sprint, then release planning (or a product roadmap) may not be needed at all.
I especially warn you against taking too long to do release planning. Many people
think too much up-front, expecting to arrive at close to perfect information. In our
business of new product development, I have never seen anyone have close to
perfect information up-front. Usually, to use technical terms, we are lucky if we
have not too crappy information up-front.
But I think some people in Agile also think too little (almost not at all) up-front. And
useful information or disagreements are not sufficiently discussed.
So, use good judgment in balancing these concerns. Both, in my experience, are
legitimate concerns.

Why Agile Release Planning?

The phrase release planning is apparently a loaded phrase for many people. My
suggestion: when talking to others, be sure you are talking about the same thing. And
expect good communication to take longer than usual.
We probably should define release planning. I find there are many different definitions
out there. I can be certain that some readers are right now imagining a very different
elephant than what I am trying to talk about. You may be imagining something closer to
Waterfall Release Planning. And I mean agile, adaptive release planning. But hold off
for a moment on a definition
I led a discussion at the Ottawa Agile and Scrum groups a few months ago.
I asked the group to come up with some reasons to do Release Planning. In essence, they
represent the meta 'purposes' of release planning. Purposes that one's practical approach
to doing Agile Release Planning should try to optimize.
The group came up with many good ideas, almost all of which I agreed with.
Here are some they did not identify (at least according to my poor memory):

1. Team building. A set of work or exercises that allows the newly formed Scrum team
to start to think of themselves as a team, do some Forming, Storming, Norming, and
otherwise start to become a team. (I do not mean team building in the kumbaya sense; I
like 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 is
all about. In waterfall release planning, we have no means (or only a poor means) to
identify where we disagree. If agile release planning could only identify (better) where
we 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 the
whole team to be, at a working level, on the same page about the product features and the
effort. 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 the
team might do Release Planning differently than if one were not trying to go after these
goals. I think #3 and #4 are very important.
Joe Approach Summary

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, if
they 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 Release
Plan Refactoring every Sprint. (And possibly some Sprints there are no changes.) The
adaptiveness 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 to
maximize the value from the good changes (eg, learning).
Again: I do not guarantee that release planning is needed in all situations, nor that this
approach 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 all
of them. My experience is that everyone I have done this with has liked it after they did

it. And thought it was worthwhile. And actually did almost all of it (and almost all that it
implies to me, but is not stated here).
A quick summary of the initial quick agile release planning. We work on the following:
1. Vision
2. Product Backlog
Roles
User Story Workshop
3. Business Value
BV Drivers
Priority Poker BV points
4. Effort
DOD (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 3
sprints, and then release to the public a much more solid plan. Nonetheless, in every
sprint 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 team
arrives 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 had
before. And that is tremendously valuable.
Note: If they do really bad or no release planning, I think it increases the chances a lot
that the stories are not small enough. This means that lots of stories just can't get to
done, done in the sprint. So, in that and other ways, good release planning is linked to

having good sprints! Now, this problem (stories too big) can be fixed later, but wow, you
will also have plenty of other problems then. Try to do Scrum as professionally as
possible from the beginning.
* * *
Now I will describe in a practical way, how I have a decent Team work through initial
Release Planning. (Note: This booklet only describes agile release planning for one
team. Later I may add notes about how to do this in a scaled situation (multiple teams)).
Vision
The first step is Vision. We define the vision, and make sure that all the right people see
the 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. The
Scrum Team includes of course: the implementors, the ScrumMaster, and the Product
Owner.
The business stakeholders (BSHs) are the other key people associated with the team that
provide key input about what the product should be. (Note: BSH is not a defined Scrum
role. 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 the
Scrum Team is 7 and the BSHs are 4, we already have 11 people in the release planning
meeting(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 participate
enough to provide valuable input. It is mainly the Product Owner's job, in my view, to
make sure these are the best possible people, given the specific situation. Often the
Product Owner must seek help in selecting the BSHs.
In my experience, the BSHs are never perfect representatives of 'the customers' of the
product. 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 or
mostly 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.

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 minutes
to your bosses' boss.
We particularly like this format, which comes from Geoffrey Moore's book, Crossing the
Chasm:
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 key
numbers 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 they
thought 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't
know 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 tend
to want to be on different pages, it seems.
How: We find this typically takes about 1 hour. Sometimes less, sometimes more. We
find it is useful to do 15 minute timeboxes, to check if there is too much aimless or
circular 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 the
vision) 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, must
improve 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

straight down, this is the worst project you have ever been on. If the thumb is pointing
straight up, this is the best project ever. Half-way, this is just an average, typical project
around 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 the
facilitation. The SM checks the time boxes, and tries to assure that everyone talks the
right amount. The Product Owner is always assessing: have we said the right things so
that 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 get
bogged 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 be
uncomfortable moving on, remind them of this.
Product Backlog
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 Product
Backlog Items, then the wording of this section would be changed a fair amount. But I
think 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 business
stakeholders you can get. They are never perfect, but at least they are the best you can
get. 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.
What: We want about 5 to 7 roles. These are the roles to go in the User Stories. (Not the
roles 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 per
2 week Sprint. 6 months work is 13 sprints. 13 x 8 = 104. Now, those 104 stories are all
small enough for a Sprint. So, in initial Release Planning, we can be pretty happy with
somewhat less granularity. So 50 stories would be good (average about twice as big as a
Sprint-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 only
produce 42, we are probably still at a good level of granularity for initial release
planning. 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), then
you 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 if
they 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 to
either 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 good
story.
OK. Now, with the Roles, the whole team starts to write stories. We let them selforganize. We give them 15 minute timeboxes. At each 15 minute break, they "check
in." They inspect progress and see if they want to adjust anything. Usually they see that
they want to write stories faster.

Typical productivity for a team is to average about 1 story per minute. So, in about 50
minutes.....50 stories. If your team is faster or slower, is it usually not a big deal. But that
gives 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 needs
improving 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 he
envisions. 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 of
the 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 a
similar 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.' This
is far better motivation than we get from 'the mushroom treatment,' which is de facto the

most common thing. (The mushroom treatment is where the team is kept in the dark and
fed 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 team
checks in. Are we going too fast or too slow? Anything we should change? Who is
talking too much, who too little?
Usually the whole thing can be done is 60-90 minutes. But really it is not a problem if it
goes 120 minutes. Or even more. The main thing is, as SM, if one guy gets talking and
worrying, and nothing is getting done, you can't let the team just spin. Someone must fix
it, 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 'create
anything' 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 do
this, 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 second
time.
Top Down/Bottom Up. I find some people are top down thinkers and other are bottom
up 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 guys
will write stories that sometimes are too small. And we sooner or later need to combine
stories.
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 a
user story format, I say: ok, just write something as a PBI (product backlog item). Maybe
later 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 of
work. Ballpark. (It is just a gut feel at this point.) Which is a great start for the Release
Planning.
These user stories (or PBIs) are just the right middle level of 'features' for everyone to
have a clear enough picture of what the product will be. It embodies the vision. It makes
things concrete for people, without getting mired in details. Wonderful. And they can do
this the first time.
Is it perfect? No. Could it ever be perfect? No. Is it a reasonable time to spend to get a
level 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 it
always happens! And will we add more stories as we are doing the Sprint? Yes, always.
Business Value
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 our
problem. How do we identify what the customer really really wants. Well, business
value 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 to
attend 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 value
vary by the situation. The product, the customers, the people involved. It may be that the
high-level basics of business value for all for-profit firms could be distilled into 5
phrases. 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 other
things. Or not.
So, they whole group gets together and discusses and agrees on the top 5 (about) business
drivers that apply to the set of work (the product) as represented in the existing Product
Backlog (its PBIs). Sometimes this will lead to the identification of some new stories (or
PBIs).
Priority Poker:
Most of you are familiar with Planning Poker, which is where we use the planning poker
cards to vote as a team on the relative story points of [new story] compared to the 1 SP on
the [reference story].
Priority Poker is very similar to Planning Poker, except that it is about business value, not
effort. In fact, we assume there is no correlation between effort and value.
So, the similarities: use a team, vote, use Fibonacci cards, discuss assumptions, share
knowledge and ideas, average the numbers after reaching some consensus, the number is
comparative, relatively quick, somewhat imprecise for each individual card but fairly
accurate over a set of cards, etc.
Some differences: a different team (the experts on business value), reference story is the
TOP 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 huddle
around 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 of
the Team who has a lot of experience with customers. Or for some other reason, knows
BV pretty well.
OK, now we have the reference story for Business Value. Then the BV experts start to
add 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 stories
in 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.

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 the
new 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." The
purpose for them being there is so they can pick up the tacit knowledge about business
value, and which stories are more important (and why).
Final review: Once all the cards have been assigned BVP (business value points), the
experts 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 a
lot bigger than the other 30's. Maybe that 70 seems too high now. The person
identifying can ask the experts to re-vote. In general, we would expect them to re-vote on
a 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 is
very, well, valuable. Of course, one person in your group may talk too much. So, the
facilitator must monitor that.
We find a time box of 1.5 to 3 hours is usually quite sufficient for 50 cards. But again, if
the 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 business
value. Yes, for example, we may have to do 5 steps in a business process, but steps 2 and
5 are exciting. The others are just chores that must happen. Steps 2 and 5, when we
deliver 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 they
must 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. He
should 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 to
force 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 the
same applies to Priority Poker.
Accuracy: Are all the cards perfectly accurately assigned BVP? No!

Have we learned a lot more about our different ideas about business value and shared that
throughout 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 smarter
about business value, in multiple ways. This should in part be reflected in changes to the
BV 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. In
the simplest world, one of the smaller stories would be worth 80 BVP and the other 4
stories 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 marketable
feature 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 user
story. Not hand waving at the vision level.
This work changes motivation. And it changes the behavior. Of everyone. The business
guys start to respect that the geeks understand them a little. And the geeks now
understand 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 few
more steps....
Effort 1
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.
So, imagine that we have 50 user stories representing roughly (per gut check) about 6
months 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 that
they currently use.
Once the workers do that, they themselves can see that it has weaknesses. And once the
process is (more) visible, then everyone can help improve it. But especially the workers
themselves will improve it. And so, they start to 'own' the process. Which makes for
better motivation. And better results.
Some in agile are concerned. Their concern is that, by writing down the process, we have
locked 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 process
visible so that it can be improved. So that it can be changed. NOT so it will remain the
same. Now, by making the process visible, we do enable anyone who sees the process to
open 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.
[Insert picture of sample DOD.]

So, before or during the Sprint Planning Meeting, the team can do many things to 'get the
stories 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 about
Story 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.) In
this (short) conversation, all 3 people try to assure they are on the same page about the
story.
Then we list everything that the Team says it can and will do to get Story 1 to a done in
the Sprint.
In my opinion, the last step (or near the last) must be PO Review, meaning that the PO
looks at the working product and gives feedback. If the PO feels the customer will not
like 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 the
live 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 we
can'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 to
improve their own process.
Planning Poker
Now we come to the point of describing Planning Poker. This is a continuation of the
discussion of Effort.
Planning Poker has been described before in the Agile-sphere, so we will be brief. It is
described at greater length many other places.
***
Some basic characteristics:
We find the 5 best people to vote on effort for this work. (About 5; maybe 3-7.) In
practice this means the Implementers in the Team. Often to call them individually
experts in estimating effort isa stretch. But the idea is that they are the best experts
we 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 all
of 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 to
make sure that the team is understanding each story correctly. Typically the PO is a
business person and in any case is representing the Firm and the Customers. So, when
those 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 get
the 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 User
Story 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 months
worth 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 the
ideal hours from all the required skill sets). [Someone should check that the story is
about the right size. But don't tell anyone, and especially don't let the experts start
thinking in units of time (days, hours). Still, if the story is too big or too small, it starts to
distort the voting, in my experience.]
The reference story is arbitrarily given a 1. Meaning, it has an effort value of 1 Story
Point.
Note: An earlier section talked about how the Team must have a strong DOD (definition
of done). The DOD should make clear what things are being done in the Sprint to get the
story 'done, done' as we often say. So, it is the effort of 'these things' done during the
Spring 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 this
reference 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 of
how much bigger the new story is in comparison to the reference story. For example, if 7
times bigger, the choice is between a 5 card or an 8 card. Likely, the 8 card will be
chosen...
If all Experts are within 3 consecutive cards of each other (ex: all have either a 5, 8 or
13), 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 talk
about their assumptions, etc. If the assumptions are business-related, then the PO can
decide 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 for
a 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 everyone
knows that it represents the story points (color and placement on the card usually make
that clear).
A few additional comments:
The discussion is actually the most valuable thing. The numbers drive a better
conversation about the more important stuff.
Sometimes important assumptions are identified. In that case, the assumption should
probably 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.

Sometimes the Experts will want to address certain general issues. The issues might be
architecture or design related. This is where the SM has to use good judgment. Typically
let them discuss for 'a while' but not too long. Maybe make one or two drawings. Make
and document a few assumptions, and then get back to Planning Poker. Sometimes one
or 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 incentive
for people to too quickly start to shade their numbers, rather than vote what they really
think. They find that George, the senior guy, is stubborn, and to avoid conflict and to
keep things going, they decide, almost subconsciously, to start voting a closely to what
George says as fast as they can. The research shows that the average is more likely to be
the correct estimate. And it actually takes less time to reach that number (if everyone is
voting honestly).
Usually one or two new stories are identified while we are doing planning poker. This is
normal. 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 take
longer. Then things speed up. On average; sometimes one or two later cards will take
some time.
Once all the cards have been estimated (for effort), all the cards should be put on the
wall. 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 reestimated, in the team's opinion. This is fine, good even. And normal. They now, as a
team, 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 by
SP. For each story. The R should not be more than one decimal place. This gives:
the low hanging fruit
the bang for the buck
the 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.

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, the
right answer in my opinion.
What ideas do we use to re-order the work? More on that in the next section.
Risks, Dependencies, Learning, MMFS, Other

Now we come to the point of (re)ordering the Product Backlog.
You will recall that the Product Owner's main goal is to maximize the Business Value
from the Team. In some time period (shorter or longer, as makes best business sense in
your specific situation). So, in theory the R factor (see the previous section) should be
the way to organize the Product Backlog, ceretis paribus (other things equal).
But of course other things are never exactly equal.
So, here is where the most uncommon thing comes into play. Common sense.
And we re-order the work based on these factors: Risks, dependencies, learning, MMFS,
and other factors.
We recommend that anyone in the Team can propose to move a user story earlier or later
based on these factors. But he or she must discuss the change with the Team and get
reasonable consensus. If there is no consensus, then the Product Owner gets the final
decision.
So, let's discuss each factor in turn.
Risks. There are potentially many types of risk. Business risk is often a big one. For
example, we need to get a feature out before a competitor. Or we have a weak
understanding of the specific detailed features needed in area X. Technology risk is
another common factor. We are about to use new technology, and we are not sure how it
will work. And there are other types of risk. In Scrum, we tend to want to attack risk
early, by doing one or more stories in that area, to see if the risk is just a worry, or a real
roadblock.
Dependencies. Again, these can be of several types. In the past, we often organized the
work mainly by technical dependencies. Since the job now is to maximize business
value, we sometimes must sacrifice efficiency of the Team. But if technical
dependencies will destroy the efficiency of the Team, then we must deal with that. (Ok,
seriously diminish the efficiency...). And there can be business dependencies as well. It
makes more sense to develop step 1 in a process before step 2. At least sometimes.

Learning. In Agile we recognize the importance of learning. We need to learn what the
customers 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 of
features that must be put together before a customer can realize the value of the whole
set. Sometimes this minimum is quite small, quite small indeed. In other circumstances
it is much larger. In general, too many of us (producers and customers) have been
brainwashed into believing the 100%-100% rule, so that we think the MMFS is much
larger than it really is. In any case, low value features sometimes must be moved up, in
order 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 user
stories. My favorite example is this: A committee is going to me in 3 weeks to decide on
the 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, which
currently would not be built until the third release, and that is assuming no new user
stories get identified, which is very very unlikely. But, George is on the committee. And
user story 87 is only 5 story points (our velocity is 25). So, we ask the Team to go ahead
and get the story done in the next Sprint so that George helps assure that the project gets
further funding. Not rational, not 'the right thing to do', but sometimes you have to deal
with real people and irrational things have to happen.
In our experience, Risks and Learning should be used more often to re-order the product
backlog. And Dependencies less often. But in any case, using the R factor solely is
almost never the right answer.
How to do this
We recommend that the product backlog already be ordered by the R factor. (The R
factor was discussed in the previous section.)
We recommend that the whole Team be there (PO, SM and implementers) and the
business stakeholders.
Then, anyone in the group can start to suggest re-ordering the product backlog based on
any 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 as
important as any other outcome we are trying to achieve. So, doing this without the
Team is not recommended.

Normally this does not take very long. Again, 6 months of work for one team is typically
expressed as about 50 user stories. So, re-ordering 50 user stories, where most do not
move, does not take long.
Completing the Plan

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 makes
managers and others realize that we will release. They only question is exactly what will
be 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. And
ask: two sprints, umm, how many features are done? Ok, three sprints, how many
features 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 we
have 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, you
must 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 days
would 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.
Let's assume the focus factor is 60%. That means, out of an 8 hour day, roughly 60% of
the minutes are usable for the project. The other minutes are used talking about the
game, taking breaks, eating lunch, getting interrupted, answering questions, reading the
email, going to company meetings, etc, etc. Maybe some work, but not work on this
project.
Calculation:
2 weeks = 10 days.
6 x 10 = 60
60 x 60% = 36
36 x (1-40%) = 21.6
21.6 / 1.5 = 14.4 Story Points for the 1st Sprint.
---We subtract the 40% has a start-up "cost" for the 1st Sprint.
The basis for 40% is, from experience, these things:
The Team is learning Scrum
the Team is "forming, storming, norming, performing.."
the Team always wants to over-estimate what they can do in a timebox.
For the 2nd Sprint, we subtract 20%. For the 3rd Sprint, we subtract maybe nothing.
You may find that these rule of thumb numbers need to be adjusted for special situations.
But they seem to work for most start-up teams.
--36 x (1 - 20%) = 28.8
28.8 / 1.5 = 19.2 story points for 2nd sprint
--36 * (1) = 36
36 / 1.5 = 24 story points for 3rd sprint
And so on...
Communicating the Plan

I tend to put pressure on new Product Owners to release earlier. They are mentally too
tied 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 earlier
release.
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 (meaning
that the current plan will be revised and improved every sprint... this is only the first
guess at the plan)... then tell that manager the truth. Here's what we guess, this is what
we are worried about. This is our feeling about how it is likely to change. And maybe
we 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 be
identified 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, the
key issue is the date.) You have to start setting expectations that the date will change if
other things change (substantially), and they are likely to change substantially. This is
not 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 in
the 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 you
have 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.
The Plan in some sense is never final. In another sense, depending on what you say to
whom, 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.
Refactoring the Release Plan

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 the
quality 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 the
basic release planning information put together in such a way that it is easy to refactor the
release plan. Or at least, much easier to change than when I used to update the Microsoft
Project 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 into
trouble.
Now, the real win was that we now have 'everyone' on the same page, at a useful middle
level 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 explicit
and 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 plan
refactoring).
It is absolutely fundamental to agile release planning that we refactor the release plan
frequently. I say (and many others say) that we must refactor the release plan every
sprint. 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:

* 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 (fewer
aggregate 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 Backlog
information 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 done
2 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 are
completely different. I think this way of thinking is unhelpful. One of the purposes of
release planning is to make the work in the sprints more successful. Release planning is
not completed until, for each sprint planning meeting, we have 'the stuff' ready for a
successful 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. We
know from long experience in our industry that 'knowing what the customer wants' is
extremely hard. Extremely. The business stakeholders are people whose time is scarce

and yet these people are essential to us in getting a much better fix on what the customer
really 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 time
efficiently.
Thus, for me it is better to think of higher level release plan refactoring and lower level
release plan refactoring. And when people say 'product backlog grooming' they often
mean 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. We
improve it. This is absolutely key to adaptive planning.
Suggested, not Prescriptive

In this booklet I made many basic concepts quite concrete. To conserve space, I did not
suggest alternatives.
It may have seemed that I was being prescriptive (a word generally frowned upon in the
agile community). This is not the case. I merely described what I usually recommend. I
respect that you have an independent mind, you know your specific situation, and you
will use common sense in applying (or not applying) these specific practices (or even
these specific ideas) to your situation.
I made the ideas concrete to make them more practical, and more visible to some people
(those of us who think more concretely). We also know that in theory there is no
difference between theory and practice, but in practice there is. Meaning, for example,
that we often have a better understanding of ideas once we can see them in practice.
Obviously, this approach at explanation has risks. Some readers will no doubt take me as
prescriptive.
Again, I think these ideas and practices work in many common situations. But I am not
trying to be prescriptive, and far less am I expecting you to take these words that way.
***
Please contact us with comments or questions. Or if we can help.

Joseph Little
jhlittle@kittyhawkconsulting.com
LeanAgileTraining.com
Blog: LeanAgileTraining.com/blog
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 20
pages.
2. Where is your scientific proof that this is the best method? A: In general, as an overall
approach, it is heuristic. I dont think any detailed approach has been scientifically
proven. However, there has been significant study on parts of the approach (and on
alternatives). 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 different
goals than the proven methods have or had. For example, estimating might be more
accurate 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 not
found them necessary when doing the initial release planning. But often extremely useful
later (for the implementers and others in doing their work). I do think that the issues that
use cases address will come up in estimating effort (and in other places), and this should
be discussed (and maybe documented) just enough at that time, so that release planning
may proceed.
4. How about more discussion of the theories behind release planning? A: Well, I do
discuss 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 will
try soon to write another booklet about that. I thought it would be more useful to many
people to describe the practical application. Some people see better when you talk
practical 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 they
discuss some other issues along the way. Those important details should be documented
in 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 in
time 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 to
discuss things quickly.

Joe's Approach To Agile Release Planning V1-06

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Joe's Approach To Agile Release Planning V1-06

Enviado por

Direitos autorais:

Formatos disponíveis

Joes

Approach to Agile Release Planning

Ver 1.06 copyright 2013 Joseph H. Little

Why Agile Release Planning?

Saved on 1/5/13 8:50 AM Page 2 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Joe Approach Summary

Saved on 1/5/13 8:50 AM Page 3 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 4 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 5 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 6 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 7 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 8 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 9 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 10 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 11 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 12 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 13 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 14 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Ver 1.06 copyright 2013 Joseph H. Little

[Insert picture of sample DOD.]

Saved on 1/5/13 8:50 AM Page 16 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 17 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 18 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 19 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Risks, Dependencies, Learning, MMFS, Other

Saved on 1/5/13 8:50 AM Page 20 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 21 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Completing the Plan

Saved on 1/5/13 8:50 AM Page 22 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 23 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Communicating the Plan

Finalizing the Plan

Saved on 1/5/13 8:50 AM Page 24 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Refactoring the Release Plan

Saved on 1/5/13 8:50 AM Page 25 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Saved on 1/5/13 8:50 AM Page 26 of 28

Ver 1.06 copyright 2013 Joseph H. Little

Suggested, not Prescriptive

Please contact us with comments or questions. Or if we can help.