Skip to main content

Can we add new developers once a sprint is started?

Last post 07:39 pm September 7, 2022 by Timothy Baffa
3 replies
10:52 am September 7, 2022

Scenario:

There are 3 developers in the scrum team. The sprint has been launched, in which only prioritized tasks (Sprint Backlog) will completed. The existing developers are 100% busy to achieve the goals of the current sprint.

However, the customer asked to develop and launch a new business process within the next two weeks. Estimated implementation 60 hours. The customer asks to add up additional developers.

More details:

  • Developers are always busy, their work calendar is planned for a long time 
  • Developers must work as a team on the product (without running from project to another project and not spreading too much attention) 
  • New developers must be immersed in their project
  • Immersion of a new developers in the project, especially for the implementation of a task with the specifics of the client's business, eats up a lot of time of the team, including the product manager.

What would be the best possible solution to handle this situation?

 

 


06:06 pm September 7, 2022

There are 3 developers in the scrum team. The sprint has been launched, in which only prioritized tasks (Sprint Backlog) will completed. The existing developers are 100% busy to achieve the goals of the current sprint.

Why aren't the Developers planning a clear Sprint Goal nor allowing for any contingency in achieving it?

My advice is to get this right before adding more people. Scrum is about learning to build the right thing at the right time.


06:35 pm September 7, 2022

There are a lot of problems in this scenario.

 

The sprint has been launched, in which only prioritized tasks (Sprint Backlog) will completed.

The purpose of a Sprint is not to "complete" the Sprint Backlog. Instead, the commitment made by the Developers at the Sprint Planning event is to the Sprint Goal. Committing to a goal rather than a body of work gives the team flexibility to handle emerging work and other events that may arise during the course of the Sprint while giving stakeholders something to expect before the conclusion of the Sprint.

 

The existing developers are 100% busy to achieve the goals of the current sprint.

Working at full capacity is not a good practice. It leaves no room for when the unexpected happens. The team may discover that some of the Product Backlog Items selected for the Sprint have unexpected work associated with them. Someone on the team may need to take unplanned time off from work. There may be a critical and time-sensitive request from a key stakeholder that needs to be addressed within the Sprint. There's work to support discovery activities and refinement. There are also overhead activities associated with the job and company that take time away from product discovery and delivery work.

 

However, the customer asked to develop and launch a new business process within the next two weeks. Estimated implementation 60 hours.

This seems fine, on the surface. Although I would question why, if it is so urgent to launch within the next two weeks, why it was an unknown until now. In my experience, not many things are discovered to be necessary and need to be delivered with such a rapid turn-around time. There's plenty of opportunity to understand what happened here. If this is a regular occurrence, the team should look at their Sprint cadence and how it aligns with cadences of key stakeholders.

 

The customer asks to add up additional developers.

If the team is a self-organizing and self-managing team, the customers don't have a place to change the composition of the team. What outcomes or objectives are the customers looking for? The team should examine those outcomes and find their own solutions, which may include expanding the team.

 

Developers are always busy, their work calendar is planned for a long time 

Why do plans extend so far beyond the Sprint? The Sprint is the team's planning horizon. Having long-term plans reduces agility as the team needs to change those plans when they learn something new.

 

New developers must be immersed in their project

Immersion of a new developers in the project, especially for the implementation of a task with the specifics of the client's business, eats up a lot of time of the team, including the product manager.

These are true statements, but I'll also go another step. Adding people to a project reduces the capacity of the other people on the team to do work associated with delivering value. Until the new team members on onboarded and trained, the stakeholders will have to accept a reduced rate of delivery. It sounds like the work is time sensitive, so it doesn't seem like something they'd accept.

 

What would be the best possible solution to handle this situation?

It sounds like the key stakeholders could use some education around Agile and Lean methods, their advantages, and how to best work with a self-organizing and self-managing team to focus on value delivery.


07:39 pm September 7, 2022

the customer asked to develop and launch a new business process within the next two weeks. Estimated implementation 60 hours. 



What is the customer basing their 2-week estimate on?   Will the customer be willing to make themselves available throughout the next 2 weeks, to support discovery and quick feedback around such an unknown requirement?



If the team working on this request is not providing either the 2-week or the 60-hour estimate, how can your company or the customer have any reasonable assurance that such a short timeframe is even achievable?



Perhaps taking the next couple weeks to discuss and refine the request, and plan for it accordingly, is a better course of action, and can dramatically improve the chances of success?



"The customer asks to add up additional developers."

  • Why does the customer believe the current team is incapable of delivering their request within the 2-week target?
  • How many 'additional' developers does the customer feel are needed to do the job?
  • Does the customer have in-depth knowledge of your company's IT processes and schedules (refinement, development, testing, release) to even make such a request?
  • Are both your company and your customer aware that there is usually a productivity decline when a team needs to adjust to roster additions or subtractions (Tuckman)?

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.