Skip to main content

Large Team... new developer and stories added mid sprint

Last post 01:53 pm October 21, 2015 by Ian Mitchell
5 replies
10:42 am October 13, 2015

Hi folks,

First of all I'm new to so hi

I've recently joined a company who are new to agile and have a massive scrum team (7 developers, 2 QA, 1 doc and 1 PM). The PM is the product owner and I'm one of the QA engineers. The head of engineering has a tight-ish reign still on the product and attends all meetings \ standups etc. The PO is only 3 months in the company and there is no scrum master either so its all a little odd to me :D

We recently gained a new member to the team who's a developer mid sprint. At sprint planning (with the P\O out on hols for two weeks) the head of engineering created some spike investigation stories and assigned them to the new developer. He put these stories within the current sprint and sized them. I questioned that this was a silly approach and the velocity, burndown etc would be redundant.

Seeing as there is a few things "wrong" or abnormal here, what would have been the best approach? We don't size non story-bugs as is and if a support issue comes in a dev\qa engineers time is taken off sprint for that too.

Thanks in advance,

03:17 pm October 13, 2015


The size of your Scrum team is large, but I've actually worked with larger teams, so while it isn't ideal, it can work.

While there is a proven negative impact on productivity anytime the roster of a team changes (add/subtract), I'm not sure if your organization is mature enough on their Agile path to understand this. Perhaps this is something to keep in mind for future engagement, especially if future altering of a team results in an unsuccessful sprint?

It seems your Head of Engineering still views his value as a command and control authority, which unfortunately runs counter to Scrum. It is typical to see attempts by management to try and "optimize" team members, instead of working to leverage the incredible potential of team capacity as a whole to get work done.

By isolating this new developer with hand-picked work, the Head of Engineering is delaying the need for the team to assimilate this new individual (Forming - Storming - Norming). My suggestion would be that if this new developer is not being allowed to work with the team on sprint stories, then they should not be considered part of the team yet. And under no circumstances should the spike work and the estimates from the Head of Engineering be included in the Sprint Backlog or velocity estimates. Those sizing attempts by the Head of Engineering are nothing but funny numbers anyway.

Best approach? Acknowledge that the work from the Head of Engineering has value (if it truly does), suggest that those spike stories be provided to the entire team to work on (with the blessing and prioritization of the PO), and have the entire team refine and estimate those stories so they are ready for sprint. If the Head of Engineering insists on having the "new guy" work on the spikes alone, simply inform them that the spike work will be managed and reported on separately from the team's sprint work.

05:57 pm October 13, 2015

Thank you for the reply!

08:01 pm October 13, 2015

> Seeing as there is a few things "wrong" or
> abnormal here, what would have been the best approach?

Help everyone else to see what is wrong first so they themselves can make it right.

Scrum is not being used in your organization, and the idea that there is a currently a Scrum team at all must be challenged. Training courses may help. Failing that, I'd promote a better understanding of the Scrum Guide. The open assessments can be used to help build missing rigor.

09:24 am October 21, 2015

Thanks Ian for your reply. Sounds like you see fundamental flaws in what we're doing. The argument was because of the size of our team that it was okay to create new "spikes\investigations" and assign it to the new dev came in mid sprint. There was no work that was previously planned for the sprint that could have been shared with the new dev.

I will check out the scrum guide etc cheers, but if I could ask what would you suggest\have done in this circumstance? Do you see other glaring issues (no scrum master etc)

01:53 pm October 21, 2015

If I observed that people thought they were following Scrum, and yet had no Scrum Master, I'd have stepped into that role myself. Understanding the organizational appetite and sponsorship for Scrum would be important to me. I wouldn't have allowed a PO to assign work to developers. I'd be keen to coach others in more appropriate practices that better implement Scrum.

From what you have described so far, there are significant and particular problems with roles and responsibilities. I recommend going through the Scrum Guide as you have suggested. After you've done that, review your own post and identify the gaps.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.