Managing distributed, part-time and virtual teams – Part 1 … Normali[s|z]ed estimations?

Let’s start a series of transparent discussions in terms of managing distributed, part-time and virtual teams, similar to the ALM Rangers scattered around the globe. The objective is to discuss concept, receive candid feedback, reflect and improve our process to allow Rangers to focus on the bits and bytes, not the process and ceremonies.

our context

Virtual teams working geographically dispersed, based on part-time and volunteer based resources. Essentially there are no bandwidth or availability guarantees.

? .1 Anyone operating in this context?

estimations in an ideal context

In an ideal world we would estimate each functional and non-functional requirements in terms of expertise, cost thereof and hours (time) required to analyze, design, develop, test and ship the feature.

Total cost = (Cost * time) + feature costs – expenses - delay costs.

Also, in an ideal world estimations, assumptions, velocity and history included on the estimations are specific to a team. In other words, team X delivering N story points is not the same as team Y delivering N story points, because a story point could be worth a tractor for team X, an ounce of Gold for team Y or 2h worth of development time for team Z.

Asking teams to estimate with a full-time mindset is already challenging. Asking teams to work and estimate with a part-time mindset, based on likely availability, is sheer impossible. Throw some dice instead, it is more accurate and lots more fun! 

? .2 Is there really a need and value in calculating total cost with part-time and volunteer based projects?

estimations in our context

To estimate within our non-ideal context and enable team members to rapidly and frequently switch between teams, or collaborate across a number of geographically dispersed teams suggests normalization of the variables. A team member needs to be able to rapidly switch context and estimate stories in team X and then in team Y, using a consistent, repeatable and simple process.

Let’s make a few assumptions (normalize). Our estimations are based on …

• Fibonacci series 0, ½, 1, 2, 3, 5, 8, 13, 21 and ¥. 0 == no effort required and ¥ implies impossible to estimate based on the known assumptions.
• Story points which represent the perceived and relative sizing of stories, not N hours. In other words, 0.5SP is not the same as 4 hours and 16 working-hours is not the same as 2SP.
• An “assumed” perfect world, with a full-time and co-located team.
• Developer/contributor and a tester/reviewer pairs working on a story. A story is done when the tester/reviewer confirms the definition of done (DoD) has been met.
• Team consensus. If there is disagreement, the stories must be discussed and re-estimated or deferred for further investigation.
• 1SP describing a story that can be developed and validated within one day. If within half a day, we could opt for 0.5SP if we were optimistic.

We then have two options:

1. Option 1 - Relative: Next we go through our backlog and find a story that requires 1SP to realise and use the story as a reference for other estimations. A 13 story point story should therefore take approximately thirteen times as much effort (not time) to ship than the 1SP reference story.
2. Option 2 – Day: Next we go through our backlog and estimate the stories based on the assumption that 1SP can be delivered within a day. A 13 story point story should therefore be do’able within 13 days.

This leaves us with a normalized way of estimating stories and the associated work. Whether you are standing in the Project A, B or C planning session makes no difference in terms of the way you estimate. This keeps things simple for the teams and variability minimized.

? .3 Which option do you prefer and why?

but what about the part-time factor?

Once we have an established velocity we can estimate how many days it may take to implement the backlog.

Duration in days = ( days per sprint ) * ( backlog size estimate / velocity ) … if and only if you have full-time resources.

We need to normalize the average velocity on a part-time basis:

• Estimate how much of a calendar month can be committed. This is the part-time factor.
• Multiply the monthly velocity by the part-time factor and round the result to the nearest integer.
• The result is the maximum a pair can deliver in one sprint.

Example

• Assumption #1: In our context a team member can commit 1/8th of a calendar month to part-time community projects.
• Assumption #2: In an ideal (fill-time) context a team member could commit 1SP/day or 21.67SPs/month full-time.
• Assumption #3: We work with monthly sprints.

Calculation

• 21.67 * 1/8^th = 2.70875 = 3SP / month part-time.
• 3SP per month per developer / tester pair.
• Stories need to be broken down into 3SP sized stories when estimating to ensure they can be completed within a sprint. Looking at the stories A-E above, only stories A and B could be tackled by a pair within a sprint.

Team

• An ideal team has 2 to 3 pairs.
• Team can deliver 2*3 to 3*3 –> from 6 to 9 story points per sprint.

? .4 How do you calculator your part-time SP limits?

The stories A-E, as shown above, are estimated at 3, 3, 5, 13 and 8 story points. In a full-time context and a 21.67 SP / month velocity we could tackle stories A, B, C and E within a sprint. However, in a part-time context, as calculated above, each pair can only commit to 3SP/sprint and can only action stories A and B. The rest of the stories need to be broken down and normalized to 3SP chunks.

summary

The definition of a story point, the estimation and the team velocity is normalized across all teams, ensuring that the estimation process and principles are the same for project A, B and C, as shown above. The two hypothetical resources working on multiple teams and projects work with a consistent process and a relative story point integer value, representing complexity, amount of features and clarity or uncertainty assurance.

? .5 Thoughts? Comments?

what’s next?

In part 2 we will discuss how we use flights, teams, epics and portfolio views on Visual Studio Online (VSO) as part of our dog-fooding.