Large Team... new developer and stories added mid sprint
First of all I'm new to scrum.org 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,
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.
Thank you for the reply!
> 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 scrum.org open assessments can be used to help build missing rigor.
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)
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.