Release Planning: Effort (1)

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

Now we move on to Effort in Release Planning.

***
The title of this blog post might be misleading.  Estimating the effort of a full Release per se is not quite what we want to do.

Right now, what we want to do is estimate the relative effort of each User Story that we have identified so far.  Or at least a large set of them, maybe the next 6 months worth of work. [Later we will use that information to take a stab at how many sprints the next release will take.]

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 gives us an estimate (a relative “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:
* 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 about 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 will have locked the process in stone. And have made people into machines.

And this concern, which is real in some situations, 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 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 X. 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 X 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 for that story, 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.

We also should document any work after the Sprint is over.

So, anything done after the Sprint to make that story (usually along with all other stories) 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 (speaking for the typical beginning Scrum team) can’t always get to “live, in production, in use by the customer” within the Sprint. At least not yet.

We think this approach to the DOD gives much more clarity and 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.

 

« « Agile’s broad adoption and mediocrity – what to do || A list summarizing Scrum » »