Adding new members to a scrum team -- does it Help or Hurt?

Consider a scrum team (component teams) operating in a producer-consumer model, catering to requests made by multiple consumers in each sprint. This team, based on their capacity and velocity, can deliver a fixed set of stories in each sprint. Which means that it is going to starve consumers if it cant keep up with their demands. In such circumstances there is a common perception that if more team members are added to this scrum team they will be able to satisfy requests from all consumers.

Adding new  members to the scrum team - does it help or hurt? Honestly, the answer is "it depends" - this situation needs to be weighed and evaluated correctly. I have come up with a list of questions based on my experience that could help  with decision making.  

• Is the current scrum team in an ideal range of 8 to 10 members?
• If it's already in ideal range, consider the impact of adding new members in terms of overhead on sprint planning and daily stand-ups.

• Are new members up to speed with the technology and scrum best practices to work in this scrum team?
• If the new team members are already hands-on with the technology and development environment (Build env, setups, hardware, tools, etc) they will be able to add value to the team much sooner.
• If new members need educational spike on new technology as well as setting up development environment then consider the overall impact on how much help/coaching  they will need from the existing team members.
• Also consider the effort needed to educate newer team members on scrum best practices which include coding practices, writing unit tests for code coverage, code reviews, etc.

• Does the addition of new team member disrupt the balance of Dev and QA ratio in the scrum team?
• If Dev/QA ratio is not managed correctly i.e. only developers are added to the team with no additional QA engineers, the existing QA engineers would have to take the load of extra testing, or team will have to cut down on new features being developed which would defeat the entire purpose of adding new members. 

• Are new members just added on temporary basis or is it a permanent move?
• The answer to the above question will vary depending on how the team is structured and organized.

• Are new members being added mid sprint or at the beginning of the sprint?
• Based on when the new members are added re-planning and re-assignment of tasks and stories might be needed.

It takes a while for scrum team to become self organized and execute to plan every sprint. Adding new members to the team can bring positive energy and help with the momentum of the scrum team or it can disrupt the team momentum. Careful evaluation should be done based on answers to the above questions. 

Sprint Burndown says a lot about your scrum team...

A Burndown chart is the graphical representation of amount of work left to do (y-axis) versus time (x-axis) and can help get a good heart-beat on how a scrum team is performing.

Some questions that Burndown can help us answer are:

1. How good is this team with the planning?
2. How well is this team executing against the planned stories in a Sprint?
3. Is this team self-organized and are they working in unison as a "team"?
4. What improvements can this team make?

Let us take few Burndown examples and try to answer the above questions.

Ex. 1: Line 1 – the Blue Line:

What does Line 1, the Blue line, tell us?

1.       How good is this team with the planning?  Not too good. This team's Burndown never reached zero. This might mean many things –

·         They might have planned for more stories then they could deliver in a Sprint.

·         They might have discovered unknowns after the planning meeting which translated in creation of new stories/tasks.

·         Sprint priorities changed after planning and that resulted in churn of stories.

·         The code quality of feature delivered might have been poor and that translated into defects, increased technical debt and eventually additional tasks/stories in the current Sprint.

2.       How well is this team executing against the planned stories in a Sprint?

·         Honestly, not too well. Their Sprint Burndown is all over the graph.

3.       Is this team self-organized and are they working in unison as a "team"?

·         It might be premature to deduce anything directly from this line. However, if this team has been in existence for a while, it would help to see their past Sprint Burndown and validate if similar trend occurred in the past.  If yes, this might be an indication that the team needs some extra coaching.

4.       What improvements can this team make?

·         Sprint Planning: This team definitely needs to improve in their planning. They should spend more time designing their stories upfront and might also consider breaking their stories into granular tasks.

    

Ex. 2 : Line 2 – the Purple Line

What does Line 2, the Purple line, tell us?  

How good is this team with the planning? 

·         From the first look one might get an impression that the team did well as their Burndown reached zero. But if looked at carefully, the story Burndown rate was way off the ideal Burndown line. Another thing to notice is the steep dive in the Burndown towards the middle. The steep dive can mean one of the following:

1.       The team did not proactively update daily data for the Burndown charts.

2.       Uncompleted stories were moved out of the current Sprint

The answer to rest of the questions is similar to questions from “Line 1”

Ex. 2 : Line 3 – the Green Line

What does Line 3, the Green line, tell us?  

1.       How good is this team with the planning?  

·         Good. They planned enough stories to keep them busy through out the iteration.

2.       How well is this team executing against the planned stories in a Sprint?

·         Good. This team executed to the plan – They inspected and adapted throughout the Sprint. 

3.       Is this team self-organized and are they working in unison as a "team"?

·         Yes, if this is the pattern they have achieved consistently in last few Sprints.

4.       What improvements can this team make?

·         Does not look like this team needs any help as they executed to the plan. However I  think there is always a scope for improvement in planning.

There are many other Burndown patterns that can be analyzed in a similar manner. An additional pattern I can think of for a Sprint is:

If team plans fewer stories than the available capacity, the Burndown will be under the ideal line and go to zero sooner than the end date.