Looking for capacity planning resources and help
Hello, all, I am currently looking for advice for our unique take on scrum. Think scrum of scrum - ish we have separate pods of interns working within their department (ex UX/UI, Front end, Back end, etc etc) on 3 mth contracts on a viable product. The need for the pods is so that when interns leave, we still have adequate knowledge transfer, and the project does not come to a halt. There have been no issues of too many cooks because they all assign tasks and work together when needed. We then collaborate together in general stand-events to ensure cross-functional success.
With that in mind, we are currently having issues with our UX/UI lead becoming overloaded with validation tasks, causing a bottleneck for the devs. My job as the project manager and scrum coach is to help facilitate change on the project level and help create processes that work for us etc. etc.. I am looking for both when to introduce capacity planning and resources for setting up an easy-to-use Miro, like a template, so they can estimate what they can get done in our 2-week sprints as independently as possible.
I think this should be done before user stories are pulled from the project backlog into the sprint backlog; however, to do that, the team would also need to create their tasks and est their points for said tasks. Looking for any ideas.
Additional info: We are starting sprint 4 but some teams are also finishing up 2-3 as they were shaky iterations at best due to the lack of processes I am trying to create and refine as we go along. Because of the timeline, I am trying to balance their need to work and the need to organize, but the last thing I want is an overloaded team member, especially when it affects the project's deliverables. Any advice on how to approach this and propose a workflow change is greatly appreciated :)
also due to 2-3 still unfinished, we don't really have accurate velocity numbers. I know this will get better as time goes on, but we need a solution now to help address the current bottleneck and future ones. I suggested holding off on sprint four, but the devs wouldn't have it, which I totally understand as they have been at a standstill and love what they do
Why do you want the Developers to estimate as independently as possible? They should estimate collectively, and take joint ownership of the work they choose for meeting a Sprint Goal commitment. If they don't, silos and bottlenecks are indeed quite likely to emerge, amongst other problems.
Keeping a fixed sprint length builds predictability and cadence, which helps with estimation and forecasting during future sprint planning events, among other advantages.
Therefore, extending sprints to accommodate unfinished work is not advised. Instead, treat unfinished work as input for improving future sprint estimations.
Regarding the UX/UI lead acting as a bottleneck or gateway, the team needs to be able to verify their own work. If they are interns and currently lack the necessary skills, they should be coached so they can take ownership of their work. Scrum encourages self-managing teams, so validation should be handled within the team rather than relying on a single person.
The sprint review provides an opportunity for stakeholders—including the UX/UI lead—to review the work. This ensures oversight without disrupting the team’s workflow.
In summary, keep sprints at a fixed length and work on upskilling the team so they can validate their own work.
Hi
UX/UI lead becoming overloaded with validation tasks, causing a bottleneck for the devs.
Did you investigate why there is an overload here ? It might be due to the experience level of the interns who do the work and this work needs to be verified by the lead. As it is too many chopping and changing in the scrum team does create issues and in your case you have interns who are there for 3 months and are replaced. As suggested the interns should be coached to ensure that they themselves can validate their work and should not depend on someone else to validate the code (there could be few critical ones which can go for validation though)
I am looking for both when to introduce capacity planning and resources for setting up an easy-to-use Miro, like a template, so they can estimate what they can get done in our 2-week sprints as independently as possible.
Estimation should be done by the whole team together. For the capacity planning you could use a simple template to check availability of the team members during the sprint (in days/hours etc.) and adjust velocity to ensure you plan for what you can deliver. All this should be done during the Sprint planning event.
I know this will get better as time goes on, but we need a solution now to help address the current bottleneck and future ones. I suggested holding off on sprint four, but the devs wouldn't have it, which I totally understand as they have been at a standstill and love what they do.
Have you discussed this issue during the sprint retrospective? What do the team members think about the solution for this issue? Holding off the sprint is not recommended and you should probably look closely at how much you commit and how much you deliver and plan the sprint accordingly (even if it means taking only few features in the new sprint)
Looking for capacity planning resources and help
I don't think you have a capacity planning problem but you do have several others. For example, your refinement seems to be inadequate if there are teams still trying to "finish" previous sprints. To me that indicates that they took on work that they did not fully understand. If there was more time spent discussing the work as a group to gain better understanding, it would be easier for them to decide if they could actually get the work done in a single sprint. And if not, they could find ways to break it down further in order to do so. Since these are interns, they may not have the experience necessary to do that so you could benefit from having some experienced engineers "pair" with them to coach them through the work. Do not let them do the work, they need to teach the interns how to do it.
Others have called out something else I see. The UI/UX Lead being overworked checking the interns work indicates that they interns might know how to write code but they don't know how to develop software. Part of developing software is ensuring it works properly. That implies testing, either automated or manual. From my experience, this is not something that is taught in college. So, again, experienced engineers can help them learn. And emphasize the need for automated testing as much as possible because it can also be included in code reviews.
From your description it seems to me that you aren't necessarily contracting in interns. Internships usually mean that the individuals have the opportunity to learn about practical business from individuals that are experienced. It sounds like you are trying to hire some low experienced developers to churn out code at a lower cost than hiring experienced developers. I don't mean to be rude. I rewrote those sentences 10 times before I decided to go with those.
All of the suggestions you received prior to mine are excellent. But one thing you mentioned and a couple that you didn't raised flags with me.
Hello, all, I am currently looking for advice for our unique take on scrum. Think scrum of scrum - ...
This immediately put me on alert. Also the fact that you never mentioned anything about someone fulfilling the Scrum Master or Product Owner responsibilities. It makes me think that your "unique take on scrum" is to have a list of work that you call a product backlog and to create timeboxes called sprints. There is nothing wrong with trying to create your own means of managing work. I've done it with success. But don't forget that any methods that help an organization move quickly will be based upon empiricism. That means that you have to constantly inspect the results of what happened looking for ways to improve upon them. The best suggestions come from the ones that were involved in what happened. If you just go outside the organization for help, you are not getting the best answers.