Agile Estimating and Release Planning


Following is my rough notes from Mike Cohn’s Agile Estimating and Planning Course which I strongly recommend. I hope you will find some useful sentences within the lines.

Task Dependency

Task independence

Tasks are not independent in Software Development.

Central Limit Theorem (CLT): The sum of a number of independent samples from any distribution is approximately normally distributed.

According to the CLT, If tasks are not dependent on each other we can say that if the first independent task "A" takes %50 longer, depend on this we cannot say the other ones would take %50 longer, too.

But if the following tasks "B" and "C" are dependent on "A", and if those are similar tasks with "A", we can say, or should expect, that "B" and "C" are also take %50 longer than expected.

Student syndrome

“Starting a task at the last possible moment that does not preclude an on-time completion.”

It is wrong approach. Lets say that we have a task estimated as 7 days and we say 10 days with Local Buffer:

Task time (7 days) + Local Buffer (3 days)

If we add local buffer (individual work time) at the end of this, there would be no problem most likely and the task will be completed in 7 days and we would have 3 individual work days.

If we put the Local Buffer in the front of the task, and we behave like this usually, the task will take longer than expected:

Local Buffer (3 days) + Task (9 days)

Short iterations in an Agile development process reduce the impact of student syndrome. Because there is no big paper to read and to prepare to task, because there is no so big task here.

Lateness get passed down to the schedule

Dependent tasks impact each other and lateness passes down to the schedule.

Release Planning and Iteration Planning

Working with iterations reduces the impact of student syndrome.

“It is better to be roughly right than precisely wrong”

John Maynard Keynes

Mike Cohn says, “Estimate always need to be accurate”. We should be accurate and precise together. There should be a balance between them.

Agile Planning

• Agile Planning is more focused on the planning than the plan, the benefit is in the planning activity not in the piece of paper.

• It encourages change with plans that can be easily changed

• It spreads the planning throughout the project, dont blow the planning budget up-front

So a good plan is one that is always accurate but only as precise as it can be

Here is some examples :

In January, you initially tell your customer that you’ll be done in August or September and the project is later released on 28 September.

In January you provide an initial estimate of “October through December.” In June you revise it to “October or early November.” You later finish on 5 November.

Why is it important that we focus on planning instead of the plan?

Because plans are point-in-time predictions about the future and the future is not always what we anticipate.

Because it’s during the act of planning that we create value. The plan is just a document or other artifact.

Because the plan will change. But all the thinking that went into planning will remain valuable even when the plan changes.

Working in the right order

Some reasons to work slightly out of order

• Synergy between items

• Size of work

• Dependencies

• Availability of skillsets

and more..

Sometimes the team could not work on the prioritized item since it is not ready.

“Working slightly out of order can improve throughput”

The Iteration Planning Meeting

Iteration Planning Meeting Purpose : Selecting and committing to a set of product backlog items to be delivered is the purpose of the iteration planning meeting.

Inputs : Product backlog, team capabilities, velocity, initial iteration goal

Participants : Product Owner, Scrum Master or Coach, Team

Output : Iteration goal, iteration backlog

Iteration goal example : Implement basic shopping cart functionality including add, remove, and update quantities.

Bad example : Do the six user stories we’ve committed to

Itreation goal provides focus for the team. It is useful to share with managers and stakeholders. Managers dont want to know each tasks that team is working on. It esentially serves the target of the iteration. It is an optional artifact. Not every team finds it necessary.

Four steps :

1. Determine the capacity

2. Refine Iteration goal

3. Define commitment

4. Acquire confident

Velocity Driven Iteration Planning

Velocity : The amount of work planned or completed in an iteration

Determine capacity : There are two aproaches - Look at historical average or most recent velocity

Define Commitment : Select a set of product backlog items up to that velocity

Acquire confident : Create a list of tasks and decide if the work can be completed

Commitment Driven Iteration Planning

Estimating

Determine the capacity individually first. Determine available hours per week for each individual and find the total capacity. And then follow the burndown chart and update the team capacity. Compare them with available hours.

The team should take into consideration the corporate overhead and unplanned time for each iteration.

On burndown chart sometimes we can see dramatically decreasing. It means that there is over estimating. And next sprint It should be set the capacity under the prior capacity how the decrease there is.

Commitment Driven Iteration Planning Example

Lets imagine that we have following team

2 C++ developer

2 Delphi developer

2 Tester

In each time picking up a user story from product backlog the team ask themselves the question, or scrum master ask them; “are you commit?”.

In an iteration planning meeting at the beginning, while team splitting stories into tasks, it might seem has no meaning. The team might say that “of course we are commit”. In time it gains more meaning. For example suppose that beginning tasks are C++ tasks and C++ developers and testers capacities close its limit. Later although that tasks are related to Delphi, C++ developers and testers should think carefully to say commit. So it is so important that the team should ask themselves each time while stories spliting up tasks and being estimated.

Which type of iteration planning is best

Velocity driven is:

• useful only over the long term

• faster

Unfortunately velocity is volatile. It moves around from an iteration to iteration

Iteration planning is not about the numbers. The purpose of iteration planning is to commit to a set of product backlog items.

The Iteration planning meeting is should be all three of these things :

• planning

• technical design

• product design