Tag Archives: ScrumMaster

Release Planning: Completing the Plan

Posted on by
Reply

As discussed in the previous post on Release Planning, the user stories are now ordered.

(Please see this post for a list of all the posts on Release Planning.)

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 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…

Communications 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”.  Too big a subject for this post.

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.

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

Self-organization

Posted on by
Reply

We have this idea in Agile, that the Team should self-organize.  This is an important idea. And also an important occurrence (eg, the reality precedes the idea).

In Agile, self-organization is compared to command-and-control.

We think self-org is an important thing to study, both in general and in your Team.

Why

Well, one, because it is just right.  People are free, and self-organization is saying that the Team is allowed to be free.

I guess this needs to be explained a bit.  Some will say: well, the company has bought their time as employees, so the company gets to define what the Team does.  Well, let is concede this at a high level; let us say that the company may define the vision or the goal or the general product.  Perhaps even the user stories.  The Team members are not slaves, but we can assume that, as employees, they agree to do the company’s work for pay.  A contract.

But, devising the work, figuring out how they will get to the goal, they should have the freedom to do.

The second main answer is: self-organizing humans tend to do better work than human ‘slaves’ (humans directed by one or a few command-and-control people).

There is lots of evidence of this. The first book I recommend is The Wisdom of Teams by Katzenbach and Smith.  This is a rather old book.  But the basic evidence is that a self-organizing team out-performs, almost always, an individual.  And to such a degree that the extra cost is well worth it.  But, you must given them some degree of ‘freedom’.

There are also a lot of more recent evidence.

Some topic you may wish to research:
Self-organization
Complex Adaptive Systems
Maneuver Warfare
Free Enterprise
Knowledge Creation

Note: Some people say that a free enterprise system is mainly characterized by (mostly) private ownership of capital (means of production). And attribute its successes or failures to that. Others focus on the freedom of individuals to make their own decisions (much like the “wisdom of crowds” idea) and on the view of the national economy as a complex adaptive system, trying to accomplish high-level economic success via many individual agents (people or companies) making their own decisions.  In our view, successful free enterprise countries exhibit many of the successful characteristics related to self-organization.

Command-and-Control Managers

Lots of managers have been taught, explicitly or implicitly, that the ‘workers’ are dumb, and the manager must tell the worker how to work.  In our view, especially for virtually 100% of knowledge workers (our domain), this is very very incorrect teaching.  But it is nonetheless, what they have been taught.

Now, some of them also understand freedom to some degree, and understand that they want the people in their group to ‘think for themselves’. But, we can say with relative assurance, most companies have a lot of people who are relatively command-and-control in their style.

And, in pressure situations (our common situation), they want to use too much command-and-control.

Again, this is not true of all managers, but of many. It depends, in part, on the company’s culture.

It is hard to convince these people to be patient for self-organization.

Teams that won’t self-organize

This is seen in real teams.

There seem to be several root causes. One, the team has been beat down by command-and-control managers so much, that they have ‘forgotten’ how to self-organize.  Another: that they Team does not believe it when managers say ‘self-organize’.  Another: The Team is fearful that by self-organizing they will be ‘held accountable’ with punishment a likely outcome.  To avoid pain, they refuse to self-organize.

Whatever the reason, two things can be said.

Many Team (perhaps with Agile coaches) do eventually break out from being ‘stuck’ (not self-organizing).

And some Teams may take a very long time or perhaps never do it.

The key advice is this: If the Team will not self-organize, or seems to want to self-organize to mediocrity, then a good manager should intervene.  Temporarily.

Perhaps prior key advice: Be patient. Often Teams will self-organize in two or three sprints.  Keep talking about it, and ask them if they need help.

Third advice: In the view of some (including me), some Teams lack some key skills to self-organize. For example, a new junior Team may not know really how to break down work into tasks for the sprint planning meeting. Sometimes ‘holding their hand’ as they mature is a very successful approach.  And 3 or 4 sprint later, they can be very good at self-organizing their own Sprint Backlog.

Learning to decide as a Team

I think each Team learns how to decide.

The first, most useful thing, is that everyone in the Team gets to offer input on a decision.

Next, the Team needs to accept that no decision is ever perfect.  Thus, decisions in general must be made, perhaps not always quickly, but promptly.

The Team needs to understand the impact of decisions on the morale of the Team and on the success of the Team.

In our view, most teams go through a forming and storming period of decision-making.  And then later get better.

Good self-organization… and better

Lots of Teams seems to self-organize well.

What is also common is for most Teams to plateau.

In part, we may say that a root cause is that most Teams want to reach a stasis… a place where things are balanced and where change slows down.

But have they reached the height of improvement?  We think not.  Some Teams have reached much higher heights.  And some Teams keep on improving.

There seem to be two main factors (or sets of factors):
* magic — or, more accurately, a bunch of things that are hard to describe.
* a bunch of factors that people talk about, and some teams study and work on

Some of these last factors seem to be quite ‘soft’.  Love, listening, creativity, heart seem to be among them.

Lastly

If you have never been on a good team, it is hard to understand what self-organizing is all about.

Within the Team, it might be rather rough and ready. But a lot depends on the specific individuals in the Team.

Agile Specification

Posted on by
Reply

This is a “just enough, just in time” concept.

Please read these blog posts:
http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html
http://scrum.jeffsutherland.com/2008/09/agile-spefiction-is-it-hoaz-or.html

OK.  So, it is something ‘written’ that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need.  To get it done right. Quickly. High quality. Etc.

What might it contain?

Well, anything useful.

I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.

It is simplest to think of the Agile Spec being ‘written’ ‘one sprint ahead’.  And being checked for ‘ready, ready’ before the Sprint Planning Meeting.  But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.

Maybe hand-written, maybe on a wiki.  Maybe in a Word doc.

Who writes it?  Well, the best people, of course (self-organize!).

It might hold:

  • the acceptance criteria
  • a business flow
  • a list of business rules
  • a wire frame(s)
  • a mock-up of the screen (if that means something different to you)
  • a simple use case kind of flow (not all the darn UML use case stuff… just something, just enough) (to me, this is a variation on a business flow, using a few specific symbols)
  • a data flow
  • new data elements (or whatever you guys call them)
  • key data elements and key values in this context
  • a screen flow
  • a simple design picture
  • a data flow, maybe simplified
  • an example (eg, if X, Y, Z inputs, then we expect A, B, C outputs)
  • anything else they may find useful to build it quickly and for it to EXCITE the customer

Any one Agile Spec will NOT have all of these things.

It does not repeat the usual BS that we used to put in specs. That no one really read.

It does not say all the stuff they know well already.  It is not trying to be ‘comprehensive’.

We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.

We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.

And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).

For some people, who maybe had too much fun in college, we need to write or draw more.

For some people, who maybe took their Ginkgo today, we need to write or draw less.

Any questions?

Ozymandias: Creation birth pangs

Posted on by
Reply

It is hard sometimes to create. We wonder, will our darlings ever survive.  I have spoken already of a book called The Courage to Create by Rollo May.

Now I want to show a short poem by Shelley.  Ozymandias, it is called.

I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desart. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed:
And on the pedestal these words appear:
“My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!”
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.

Ozymandias was once a famous king, of surpassing wealth and power in his time. And Shelley wrote this after seeing the ruins of his kingdom.  You will note that Shelley, the great poet, was not daunted by this vision of despair.

I note with irony and pun-ishness, that in our computer world, the lone and level sands stretch far away.  (Ok, Virginia, I am alluding to how sand becomes silicon, as in Silicon Valley. The valley of dreams.)

I hope that you do not seek that fickle goddess, Power.  Or wealth (perhaps slightly less fickle, if you know a good Swiss banker).

But if we only build castles of dreams in the breasts of our friends, even those dreams, once built, can die surprisingly quickly.  A new product will come along and charm them a different way.  I am sure any of you can think quickly of an example.

We must have the courage to create, and the laughter to let that beautiful creation come crashing down. And then to create again.

I will close with this quote from Henry Ford:

I cannot discover that anyone knows enough to say definitely what is and what is not possible.

The importance of a real team

Posted on by

Scrum requires a real team.

The word ‘team’ is often used, often in different ways.  So, let us define it.

According to “The Discipline of Teams” by Katzenbach and Smith, this is what you should look for:

1. A meaningful common purpose that the Team has helped shape.

2. Specific performance goals that flow from the common purpose.

3. A mix of complementary skills. Including technical/functional, decision-making, and interpersonal.

4. A strong commitment to how the work is done.

5. Mutual accountability.

For more discussion, see The Discipline of Teams.

The team needs to be small (~7), stable, cross-functional, and self-organizing.  The team is in it together.  And should help each other.

In general it is best if the team is fully dedicated to one missson, one purpose, or at least the one team’s goals.

All of these team characteristics together are key to starting Scrum.  Got to start with a real Team.

Note: Not everyone wants to be on a Team.  And for sure, not everyone walks into the office knowing how to act in a real Team.

What to do with managers?

Posted on by

First, unlike some in the agile community, I think managers can and should be useful in lean-agile-scrum.

Still, there is a lot of evidence, on many levels for two propositions:
1. Some managers can be very detrimental to a lean-agile-scrum implementation.
2. Many managers have not been well trained in how to manage. In fact, what they have been taught seems to be, to a large degree, the wrong stuff. (At least, it seems, in the US.  In other countries, this may be better.)

So, we agile advocates have a long way to go to get all of management ‘fixed’.  I mean both middle and senior managers now. (Yes, the solution for the middle managers might be somewhat different than the solution for the senior managers.)  On the right page with the right attitudes and practices that are consistent with lean-agile-scrum.

So, a few quick ideas on how to fix this:

1. Check out the “Stoos” group. A few are a bit too radical for my taste, but that group is working on ‘management’.  They have useful ideas on this problem.

2. Respect change. It is hard. It does happen. You cannot always make it happen, especially on your own schedule. But sometimes, either before or after you want, people will change. And even in the direction you want, due (partly) to the efforts you made.   …Do not let yourself get depressed, do not give up.

3. Respect the people you are trying to change, and that, at least in some ways, their concerns are legitimate.  At least from where they are coming from, there is typically some internal logic to the way they think.  … I find this is hard, because I can so palpably feel the damage these people are doing. It feels like they are trying to be evil sometimes.  Certainly stupid. And I grow impatient.  But mostly there are not (evil); they are usually trying to do they best they know how.

4. Look (again) at the standard change books. Kotter’s books. Fearless Change by Manns and Rising. Others (if you prefer). Many great ideas about getting people to change.  Most of the following are discussed well and at length in these books.

5. Make the case. Repeat it often.  It starts with a Sense of Urgency.

6. A sense of urgency, to me, starts with one person having a passion that, dammit, things have to get better. And conveying that passion. Maybe in a quiet way. Certainly in a respectful way. But in more an emotional way than a ‘numbers’ way. Although numbers usually need to be in there as well.

7. Use some experiences. Maybe from articles. Maybe from nearby firms. Maybe from your own firm. Data of one sort or another.  There are tons and tons of great articles about lean-agile-scrum now.

8. Five books for managers.
Toyota Production System by Taiichi Ohno.
Radical Management by Stephen Denning.
The Power of Scrum by Jeff Sutherland et al.
Software in 30 Days by Schwaber and Sutherland
Drive by Daniel Pink.

9. Motivation. Often the key, I think, is they misunderstand motivation. Particularly motivation for knowledge workers. This is why I think Daniel Pink’s book is so useful.

***
Please comment here. I think this is a hard problem. If we knew the answer well, this problem would be a lot better now.  So please suggest better things.

We are also discussing this topic in the Agile Business yahoo group. Please join us.

Killing Babies or Sizzling Steak

Posted on by

I thought I would share this story, with one or two key metaphors.  Perhaps useful to you.  I use them in classes quite a bit.

***
OK, the PO is trying to optimize on the Pareto idea (80-20, the vital few).

At the beginning of the project, the team looks at the release plan and says: “OMG, if we try to get all that done by Aug 15th, we’ll die!”  So the PO, realizing that even more (new) work will be identified later, gathers the business stakeholders for a meeting.

“Guys [speaking to the business stakeholders], we have to cancel from the release the bottom 30% of the stories. We just won’t get them done, or at least can’t guarantee them by that date. And we know new stories will be identified by then. I need your agreement they won’t be in the Aug 15th release.”

They look at him in disbelief.  And then the BSHs (business stakeholders) get upset.

“What the…! You haven’t even started work!  I fought and fought with my team to exclude other stuff and I fought to get those babies in the Release. And now, before you even started, you want to kill my babies!”

Suffice to say, it is not a fun conversation and they don’t want to agree.

Now, I do think the PO should make them aware that getting all stories done will be a big challenge. And if the PO can show a true Pareto curve, it is a much better conversation.  But don’t try to get them to agree at this point. Too much pain, too little gain.

***

Now, imagine later. You have built two Sprints of the top stuff. You serve it up very seductively in the demo. You can see the top BSH drooling.

You say: “George, do we have all the top stuff built for you?”

“Well, I need story 23 and 47 too. But yes, this stuff is all the top stuff. And it looks good. I mean, aside from those missing stories, it looks…give me a second to wipe my mouth…it looks r e a l good.”

“After the next sprint, when we complete some other stories and stories 23 and 47…  George, how about we then serve you up some of this sizzling steak, fresh-off-the-grill? We give you a release then?”

“Well, how about the broccoli and the mashed potatoes and the creme brulee?”

“Yes, we can give you those later, in later releases.  And how about we release you the sizzling steak _now_ (well, next sprint)?”

Now it becomes George, and not you, who gives the other BSHs the look… “guys, I think this is the best for the firm… I need you to TOFTT and let us do this release now… you’ll get your stuff real soon.”

And he looks at Mary (the 2nd BSH): “Mary, we already have a bunch of your stuff in there too. What do you think?”

Mary: “Well, it does not have everything our group needs, but, yes, I think we could make use of what’ll be there by the next Sprint. Are we really gonna get the later releases?”

Geo: “I think so. Heck, they never had this much working software before by this time.  I think we can trust those SOBs now.  Sorry, Mr PO, I meant SOB in the nice-est way.”

Mary: “OK. How about the rest of you guys?”  ….

***

So, you can see that it is a totally different conversation. But with the same effect. That we execute and release more on the Pareto idea than on the 100% – 100% rule (where we often die in the death march).

And all because we served up the sizzling steak seductively.  We did not win on logic, but on the emotion of the drool.

Now, serving it up seductively is a fine art.  Seduction.  Well, there is Joe the geeky PO and then there is Casanova or Mata Hari. (Ok, yes, an exaggerated comparison…)  Do I need to ask which one is going to serve up the sizzling steak more seductively?  Thought not.

Now, one of the key benefits of the ‘sizzling steak’ technique is that the Team now has a better life (no death march, seen to be victors). Which means they are more creative. Which means everything should be better.

***
The story and the metaphors work for me. YMMV.
It does help if the key person is not a vegetarian. And even likes steak.

Later, they will say “Oh, yeah, I liked the story about the sizzling babies.” And then they will laugh.  But they might remember it longer.

Release Planning: Product Roadmap

Posted on by

I did a session today at the Atlanta Scrum Gathering about ‘Joe’s Approach to Release Planning’.  Jason Tanner asked “what about the product roadmap?”  And his question made me realize that I have not said enough about that.

My quick thoughts.

1. You need a product roadmap. For almost all products. Well, at least almost all the products I have worked with over 20+ years.  I suppose I am not an expert on iPhone Apps, for example. Maybe they are an exception.

2. What time span should the product roadmap cover?  Yikes. This is hard question with no perfect answer.  Longer than the implementers want to think about and shorter than the ‘planner’ type wants.  OK. For most products, about 1 year.  For fast changing, fast delivery products, less than one year, maybe even only 3 months (assuming say monthly releases).  For ‘big’ products, you might need multiple years.

3. The purpose of the product roadmap is not to be right. But to generate useful thinking about ‘longer term stuff’, and provide some context for shorter-term thinking.

4. YAGNI.  First, You Ain’t Gonna Need It has proven to be a pretty good principle.  Stuff happens, and all the knowledge created to go down path A is now useless.  This principle always tilts things towards less investment in longer term planning.  But of course, this principle is not the whole story.

5. Purpose: Human beings seem to be more motivated, seem to enjoy life more if they feel there is a purpose to their lives. And a product roadmap is an example of something that can and should be used to put things in the context of purpose.

6. Identify hard-to-reverse decisions.  Many decisions or actions are easy to reverse. Some are quite hard.  The harder a decision is to reverse, the more costly, the more it is worth some time to think about it and decide with a higher chance of being right.  A product roadmap can help us identify those kinds of decisions, and put them in a context.  For example, help us understand when those decisions must be made.  What I am saying here is very similar to the Poppendiecks’ ‘decide at the last responsible moment’ concept.

7. Practical. For a team just starting Scrum with a fairly normal product, if the group seems ok with it, I like to plan about 6 months worth of work (typically one or two releases, at least as initially conceived). And stop there for now. And start Sprinting.  And then later build out the rest of the product roadmap.

Why? Because they don’t really understand the power of agile and agile adaptive planning until they do Sprints. And until they do the Release Plan Refactoring.   It’s a think-do feedback loop. They need to experience it sooner.  Then, having that tacit understanding, they start to plan better with less BS. And with more purpose.

***
Comments?

Release Planning: Effort (1)

Posted on by

Now we move on to Effort in Release Planning.

For those who have not been reading here before, this is a continuation of a series that starts here.

***
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
* Product Owner Review (any issues fixed)
* No increased technical debt
* Promoted to the QA2 Server

What I don’t like is that there is no 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 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.

***
In the next post, we will go into Planning Poker.