Estimation meeting getting dragged for hours?

In our organization all Product Owners (PO) fear or simply run away from estimation meeting. We started following Kanban and one major consideration amongst others were relief from those hour long estimation meetings.

Basically we made estimation meetings so painful that POs stopped asking for it. We started arguing about value of those estimation meeting.  I am sure this scenario is not common to us. I felt, as if these developers have been burnt by giving estimate before. I am confident, management hold them accountable for the numbers they spoke. 

I would try to resolve these issues by encouraging team to give honest estimation. I would also assured them that the number will not be taken against anybody if it turns out to bigger than what they feel. Also never use their estimates against them i.e. in reports or some charts. Remember estimates are not commitments. We estimate and then if necessary we commit. One of the most important factor in converting an estimation into commitments, are cost of being wrong. A team facing high cost for being wrong would give a different commitment from being a team which pays no cost at all. 

I would recommend explaining them the benefit of estimation meeting from team's perspective. We all know why estimation is important for client/customer/PO but why it is important to team. (Mike Cohn gave an awesome tip, which I love to follow.). Team develops credibility by giving an estimate and sticking to it. If team has track record of providing estimate and meeting them. Business will listen when team says certain deadline is impossible. I am sure every team likes to be heard. 

Cheers

Manisha

Estimating Product Backlog Items - why to do it?

In our team we have stopped estimating product backlog items.

In our context I believe it's fine not to spend our valuable time estimating product backlog item. Because, there is no need to tell, where the team would be in two or three months. Also since team is working on small small features PO wants all of them. For us having estimate will not change any behavior, so I would say it's okay. 

In my past projects we always estimated PB. An estimate represent the cost of an item and helped PO successfully prioritize the items. Also estimation helped us doing the rough long term projection on when team would be done with the product backlog items. We estimated product backlog items during our PbG ( Product backlog Grooming) meeting. We use to have PbG meetings 2 to 3 days before sprint planning meeting. This gave enough time to PO to get the backlog prioritized and ready for sprint planning meeting. At times we did adhoc Product backlog estimation based on PO's need. 

It is nice to experience both side of spectrum. 

Thanks

Manisha

How To Groom Product Backlog

Product Backlog Grooming (PbG) means keeping the product backlog well maintained. This concept has become very popular amongst teams over the past few years. Teams realize that Sprint work gets lot easier if the product backlog is in good shape. i.e. Well Groomed.

PbG is where top priority backlog items are assessed against Definition of Ready(DoR) or Conditions of Satisfaction or Acceptance Criteria. Whatever you would like to call them in your system, is basically high level test to verify the backlog item. By doing this in advance of Sprint Planning meeting, Product Owner (PO) gets a chance to add any missing details to the item before Sprint Planning meeting.  Grooming a product backlog usually involves handful of separate activities.

1) New items can be added into backlog with rough estimate from team.
2) Reprioritization of backlog items based on customer feedback, usage pattern etc.
3) Discussing top big items and breaking them into smaller items to fit them into next Sprint.
4) Adding details to the items as per DoR
5) Throwing away the items which are not needed

I would not suggest entire team to participate in PbG. However PO, Scrum Master and one or two team member should be sufficient. Lots depend upon the team semantics. Scrum Master may ask the team during standup, about their availability for PbG meeting, anybody who is not too busy during the Sprint can participate. Everybody should get a chance to participate once in couple of Sprints.

In my perspective it is lot advantageous to designate a specific time in the Sprint and do it on regular basis vs. thinking of doing it real time. i.e. whenever needed. It should be good to do it before 2 or 3 days before Sprint Planning (SP) meeting.

Thoughts

Manisha

Task finish late more often than they finish early, why?

"Failure to plan is planning to fail"     -  Winston Churchill. 
"It is better to be roughly right than precisely wrong." - John Meynard Keynes 

Planning should enable us to take right and reliable decision. Don't get me wrong, I am not asking for precise estimation.

I strongly believe in quick and rough estimation which evolves as time pass through.

In this post, I am leaning more towards what impact, human behavior and type of work we do, make on our rough estimated number.

Student Syndrome or waiting till last responsible moment ;)

Student Syndrome, refers to waiting to start a task until the last possible moment that does not preclude on time finish. (This is human nature and very difficult to change.) Lets take same feature A example. As a developer, I thought task X should not take more than 3 days but I kept one day buffer and said 4 days.

When we think we always think like below: Work (3 days) + local Buffer (1 day)

But while executing we feel very optimistic to finish the task in 3 days and we start with cleaning technical debt, preparing some flow for project or documents etc.

We behave reverse i.e. Local Buffer (1 day) + Work ( 3 days)

Finally I started my work and my work took 4 days. I ended up delaying the schedule vs. finishing on time. I had local buffer but it did not help. Therefore having shorter iteration in development cycle might help in keeping the focus vs. big iteration.

Lateness passed down (Central Limit theorem does not apply for software)

Software tasks are mostly dependent upon each other, hence the impact of delay of one task may cause delay in other another too. Let me elaborate what I mean by this. Lets estimate a feature A, which has 3 tasks X, Y, Z.  Task X would take 4 days to finish. Y and Z subsequently would take 2 days each. So initial estimate for feature A is 8 days.

For some technical reason task A took 5 days. Now obvious question would be to think what impact would it have on tasks Y and Z? Developers would mostly say other tasks would finish in 2 days each, since I learnt a lot while finishing task X.

You might think that our new estimate for feature A is 10 days vs. 8 days.  If the tasks in feature A are independent to each other, than this new estimate might be good but in most cases if task X took 1 days longer there are possibilities that task Y and Z might take longer too.  Therefore for any revision, look for inter-dependency within tasks for more accurate estimates.  

my experience
Manisha