How to handle split team Sprint needs?

Question

I'm Project Manager at my company, and we are trying to use the Agile Scrum methodology to release a software product.

We have a specific milestone (let's call it the creation of a "prototype") that we thought would take all of our departments three weeks to complete. (For the sake of this question I will simplify it and say there are just two departments: Programming and Art.) This milestone was going to be the current Sprint, and we would adhere to all of the usual Scrum guidelines.

However, it was later revealed (mid-Sprint) that there was a piece of the work that would take the Art department an unknown amount of time to complete. They are able to come up with an estimate for how long this type of work would take after being able to do one version of the work within one week. After that one week, they will be able to give an accurate estimate of how long the full amount of work will take, and we can make a plan for how long it will take to reach the milestone/completed prototype.

This presents my problem. Our Programming department does not need any additional time to complete their work for the milestone... they still only need three weeks. However, the Art department needs one week until they can figure out what their full time estimate will be and until we can determine what the "true" end time for this sprint will be.

So:

• Should I make this one week its own Sprint instead, and then have the next Sprint be to hit the milestone prototype once we know how long it will take?
• • If I do this option, though, won't that make it confusing for my Programming department because now they have a one week "sprint" with an arbitrary end point in the middle of their work?
• Should I split my team and give them two separate sprints? One for the Art department and a different, simultaneous Sprint for the Programming departmet?
• • If I do this option, will I be violating the idea that Sprints are supposed to happen with the full team together? I also worry if it will make our digital to-do lists confusing to look at when "In sprint" for tasks is not referring to the same thing for everyone reading.

What's the best move here? I'm a bit at a loss for how to tackle this and have a decision justified by the Scrum standards. Thanks so much.

Answer 1

Your decision has nothing to do with your current problem.

Your current problem is something unexpected happened and your sprint goal is in danger. Your options are

• call off the sprint and start a new one
• let the sprint run its course, knowing the goal won't be reached
• reorganize the teams priorities so the goal can be reached

Since you cannot reorganize the team to reach it anyway, because all the programmers looking over the art department's collective shoulder isn't going to make them more productive, the normal way is to just let the sprint run and maybe set a new goal. Cancelling the sprint only makes sense if something catastrophic happened. Lets say your boss saw the design and halted the project until a complete redesign by external people took place. Then letting the sprint run its course would only mean your whole team twiddles their thumbs waiting. But as it is, people can work. They just won't reach the milestone (what exactly is that? There are no milestones in Scrum btw...).

So the answer here is: keep the sprint. Something unexpected happened, so maybe it will take another sprint to get it done. That happens. A sprint is a time-box, not a milestone-box. You inspect what you have at the end, not end when you have something deemed inspectable by others.

But to your actual problem: why are the art department and the programming department one Scrum team? Can they help each other out? Do they have shared goals they can share the work on? If there is nothing to do art-wise, do the artists test or otherwise help the programmers? If there is nothing to program, do the programmers help the artists in any way? If the answer is "duh, no!", then they are not one team. And artificially treating them as one team will only lead to friction and problems.

My guess is that you are "using the Scrum Methodology" in name only. Maybe you have Daily meetings. But you said you are the "Project Manager". You have "Milestones". Apparently, you have no Scrum Master, or they would have answered this question already. So you are not actually doing Scrum. My suggestion is, either do Scrum, and get a professional coach to help you restructure the company to really do Scrum, or don't call it Scrum, call it whatever you like and do what fits your company best. Following the Scrum guide... a little bit isn't going to do you any good. It helps just as much as eating healthy... a little bit between two meals at Mc Donalds. Scrum is great, but you need to actually do it, not just follow some of the rules sometimes.