Home > Uncategorized > Impact of team size on planning, when sitting around a table

Impact of team size on planning, when sitting around a table

A recent blog post by Allan Kelly caught my attention; on Monday Allan sent me some comments on the draft of my book and I got to ask for a copy of his data (you don’t need your own software engineering data before sending me comments).

During an Agile training course he gives, Allan runs an exercise based on an extended version of the XP game. The basic points are: people form into teams, a task is announced, teams have to estimate how long it will take them to complete the task and then to plan the task implementation. Allan recorded information on team size, time spent estimating and time spent planning (no information on the tasks, which were straightforward, e.g., fold a paper airplane).

In a recent post I gave a brief analysis of team size on productivity. What does this XP game data have to say about the impact of team size on performance?

We don’t have task information, but we do have two timing measurements for each team. With a bit of suck-it-and-see analysis, I found that the following equation explained 50% of the variance (code+data):

Planning=-4+0.8*TeamSize+5*sqrt{Estimate}

where: TeamSize is the number of people on a team, Estimate is the time in minutes the team spent estimating and Planning is time in minutes the team spent planning the task implementation.

There was some flexibility in the numbers, depending on the method used to build the regression model.

The introduction of each new team member incurs a fixed overhead. Given that everybody is sitting together around a table, this is not surprising; or, perhaps the problem was so simply that nobody felt the need to give a personal response to everything said by everybody else; or, perhaps the exercise was run just before lunch and people were hungry.

I am not aware of any connection between time spent estimating and time spent planning, but then I know almost nothing about this kind of XP game exercise. That square-root looks interesting (an exponent of 0.4 or 0.6 was a slightly less good fit). Thoughts and experiences anybody?

Update: I forgot to mention that including the date of the workshop in the above model increases the variance explained to 90%. The date here is a proxy for the task being solved. A model that uses just the date explains 75% of the variance.

  1. John Carter
    August 19, 2018 20:59 | #1

    -4+0.8xTimeSize? Don’t you mean TeamSize?

    And what _exactly_ is the Planning variable? Man hours expended in planning? Length of planning meeting?

  2. August 19, 2018 21:34 | #2

    @John Carter
    Oops, yes. Thanks.

    I would expect the Estimate time to include a TeamSize component, but without information on which teams estimated the same tasks it is not possible to model this.

    I have updated the post to include what should have been there to start with.

  3. August 22, 2018 14:26 | #3

    Thanks for looking at this Derek, very interesting.

    @johncarter in the data I recorded:
    – Team size is the number of people in the team
    – Estimate means time to estimate 7 simple tasks, from my handing out the tasks to all 7 haunt estimates in seconds
    – Planning means the estimate time plus the additional time to plan out the work (prioritization, any discussion of work and any task assigments)

  1. No trackbacks yet.