An assortment of thoughts.  Mostly tech related.

Brooks Law - Lines of Communication calculator - SIRI Shortcut

I’ve always loved the power of this visual from Lighthouse, representing Brooks Law and the number of lines of communication that exist in a team of a given size. It really demonstrates the mounting challenge of keeping people on track and in sync as team size grows:

Image Source:  Lighthouse

Image Source: Lighthouse

Large team size presents significant overhead in terms of comms between the members of the team. The Scrum Guide has standardised on 6 +/- 3 as the best team size - so, between 3 and 9 people, PLUS the Scrum Master and Product Owner.

I can never remember the formula to calculate the number of relationships, despite it being quite simple - n*(n-1)/2 - so I put together this super-simple SIRI shortcut to help me out.

So…when you need to put the case forward for smaller team sizes this handy Siri shortcut can quickly prove a point. Simply enter the number of development team members and it spits out the number of lines of communication between the team members. Enjoy!

Click  here  to download the Brooks Law/Lines of Communication ‘calculator’ shortcut to your iOS device…

Click here to download the Brooks Law/Lines of Communication ‘calculator’ shortcut to your iOS device…

Velocity and Capacity considerations for Sprint Planning

Velocity and Capacity are both critical metrics to consider in Sprint Planning.  As a reminder...

  • Velocity is a running average of the amount of user story points a team manages to achieve in its sprints - a historical view of what has happened

  • Capacity is a way of forecasting the team's availability (in the future) to work on stories in the upcoming sprint(s). Capacity is measured in time.

Capacity is affected by activities which can be represented as overhead - fixed and variable.

  • Fixed overhead represents the routine activities that the team members must be involved in sprint to sprint - such as Sprint Planning, Daily Standups, Backlog Refinement, Showcases/Sprint Reviews and Retrospectives and preparation for those activities. This can be considered as 'Scrum overhead'.  All of those activities take time and for a typical team using Scrum that adds up to around 20-25% of each team member's time each week

  • Variable overhead describes other occasions - this might be team offsites, town hall meetings, holidays, workshops and other non-Scrum/non-user story related work which affect the teams availability to get stuff done

So...consider this example:

Let's say a team has 4 team members that do the actual story work each sprint.  The team works to a 2 week sprint cadence which represents 10 working days. A working day (for sake of easier calculations) is 8 hours long.  Let's also assume too, that the team has an average velocity of 64 story points per 2-week sprint.

So, the team's capacity (incorporating Fixed overhead) can be determined as follows:

4 (team members) x 10 (days) x 6 (hours ie. 8 hours less 25% in fixed overhead) = 240 hours of time

This is the team's Normal capacity - which describes the maximum time the team has available to work on delivering User Stories.

Now, for an upcoming sprint you then deduct any Variable overhead that you're aware of.  Eg. Steve is going to be on leave for one day (6 hours), and the whole team has a half day workshop (4 hours x 4 team members = 16 hours) for a total of 22 hours of Variable overhead.

The team's adjusted capacity for the next sprint is 240 hours (normal capacity) - 22 hours (variable overhead) = 218 hours adjusted capacity.

Now, armed with this information you can calculate expected velocity for the upcoming sprint.  You do so with the following simple formula:

Adjusted Capacity/Normal Capacity * Average story point velocity = Expected story point velocity

e.g 218/240 * 64 = 58.13 points

During Sprint Planning you'd then look to bring into your sprint backlog about 58 points of work for the upcoming sprint.


T-shaped people and broken combs

We talk a lot about Agile teams being cross-functional or multi-disciplinary, but in Agile we need to be careful that we encourage one type of team, and not the other, and that we understand the difference between the two terms.

So...what IS the difference?

In my opinion, A multi-disciplinary team (MDT) is a team made up of a group of people who hold different disciplines. People in multi-disciplinary teams tend to by I-shaped.  That is, they have a very deep expertise in a specific area, but much less breadth across other skill areas.


What Agile teams do best with is T-shaped people. T shaped people also have specialties - a strong depth of skill in a given area - but they also have skills (breadth) spread across other areas of the team's knowledge work, too.  Just like the uppercase 'T' - depth and breadth of knowledge.

In Agile teams, and especially in Scrum, cross-functional teams are critical to success. Cross-functional teams have all of the skills needed to get the work done, with plenty of skills overlapping to reduce the dependency on the skills and expertise of any one team member.  Work, and consequently the 'success' of the team, in Scrum, is the collective responsibility of all of the team members.  In a Scrum team all team members must collaborate and pull together to get the team over the line - so most team members should be able to muck in and assist with most of the tasks the team has before them.

The long term goal of Agile teams is actually to achieve something higher still.  Beyond T-shaped people there's discussion about the need for 'broken combs'...

Imagine the teeth of a broken comb with some teeth missing completely and others which are much shorter.  The comb's teeth represent skills/functions.

Pieces of broken combs have some breadth, but they also have some depth, to differing degrees, across a number of skill or functional areas. Imagine each person on the team being represented by a small piece of the comb...with a few full length 'teeth' and a few that they are developing.  Collect and assemble these different pieces together and you have enough overlap in skills to make a truly cross-functional team.

Agile teams therefore need T-shaped people or 'broken combs' to be truly cross-functional.  That is, each team member needs to be a 'generalising specialist' having skills across a variety of skill areas so that they can jump in, get the job done and collectively succeed in the Sprint goal.