.png){kind=logo}
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
Product Backlog Estimating Units
There are two units to estimate product backlog items. Ideal Time and Story Points. Do not confuse, iteration backlog items should be estimated in hours.
Ideal time
It is the amount of time a product backlog item is expected to take when three things are true:
It's all that you work on.
No one interrupts you.
Everything you will need is available when you start.
Elapsed Time = Ideal Time / Velocity
So you should estimate size and derive duration. Estimate size in ideal time is better. And then find the duration of work, elapsed time.
Story points
What is important with story points is that all stories that are the same size should take about the same amount of time. All ten-point stories should take about the same amount of time and should take about as long as doing two five-point stories, and so on.
Following are valid approaches for estimating a vague requirement:
Use a range.
Defer estimating until you can get more information.
Which one statement best describes what is meant by the phrase “estimate size, derive duration?
”An agile team should first determine how much work is to be done and then separately determine how long it will take to complete that work. Dividing the size of the work by the amount of work accomplished per iteration gives the duration.
Reasons To Favour
Ideal Time
Easier to start with
Easier to explain to others
It’s more palatable to management (Managers used estimates in time. Estimates in ideal time seems familiar. There is a simple math calculation. Duration (Calendar Time) = Ideal Time / Velocity) Converting story points into calendar time is harder.
Forces us to confront time-wasting activities (4 ideal days work has been completed in 20 calendar days!! So you can see easily so much time-wasting here)
Story Points
Prevent incorrect conversions to calendar days
Promote cross-functional behavior (When we are divided into functional subgroups we missed our sinergies. Using story points encoruages teams estimate together, allows to estimate collaboratively)
Points don’t decay
Story points are a pure measure of size
Points prevent unit confusion
An example of converting ideal days into calendar days. Velocity is 7 productive hours in a day. But it is a wrong approach since the ratio is only a guess. And people guess optimistically.
This is a better way, divide project size by velocity. Velocity is actual number for the team.
Final note on velocity : Velocity is always based on the sum of the estimates on the items in the product backlog. In the following example after the first iteration the team completed Item A where in the backlog in 25 ideal hrs. In the PB the item has estimated as 20 hrs. So the velocity is accepted as 20.
