Monday, December 1, 2014

Commitment driven Planning: my favorite

I have worked with multiple teams and each team have their ways to estimate and plan the work in sprint. We can plan our sprint/iteration in two ways.

1) Velocity Driven Planning (VDP)
2) Commitment Driven Planning (CDP)

We all have fairly good idea about velocity driven planning but very few of us do commitment driven planning. My team loves it, so thought of sharing our process.

To start commitment driven planning, team estimate their capacity by simply taking a guess of how many hours of plannable time each individual would be able to devote in the sprint. In subsequent sprint team adjust their time by adjusting the plannable time up or down based on their experience.

What is Plan-able time? 

We all know that if we have to be good corporate citizen, we have to attend some meetings or reply to some HR emails or support our organization ecosystem. This is Corporate Overhead and varies from corporate to corporate. First think how much corporate overhead each individual have. 

The left over should be considered your productive time. Remember productive time may not be always working on planned things

Not working on planned thing is not slack or padding or buffer but working on things which can or may occur during a sprint like, production outage, blocker bugs etc. We don't know how this time would be used but team has all good intention to pull work incase Unplanned time is not used. It is a block to accommodate emergency. Look at your sprint and calculate how much time would you need to keep aside for these unplanned activities. 

Left over time is hopefully your plannable time. This time can differ from sprint to sprint and team to team. One sprint they might have lots of support issues but another sprint it might end up pulling more features. Over the period of time it will average itself out.

Once team have the fair understanding about their capacity then team looks at the prioritize backlog. Team will commit to item by item in the backlog. They look at an item, break them into tasks and ask "Can we commit to this". If yes repeat the same process for next item. 

I prefer Commitment Driven planning because team tends to do three things: planning, technical design discussion and product design discussion vs. just planning.

Would love to hear your experience.
Manisha

***Mastery is capability in context 


No comments:

Post a Comment