9

Our two Scrum development teams are located in India. Our shared product owner is permanently relocating to the US, and we're just about to finish our first sprint. Him and the team suggested delaying the next sprint by a week while he's in transit. The loss of rhythm to the team concerns me, as well as violating one of the core rules of scrum.

I am not a part of the scrum teams, but I am a Certified ScrumMaster and have learned a lot from this site over the years, so I am acting as an agile coach within the organization.

So I was going to suggest they do another sprint anyway but just focus on technical debt and pretend they're doing a sprint where they've committed to zero story points. I know delaying a sprint is not recommended in scrum, as per the Scrum Guide, but committing to less so the team can resolve technical debt is something that's recommended in some material I've read.

The product owner prefers the team not work on any product backlog items until he can groom the backlog further. We had planned to conduct a product backlog refinement meeting, but realised that the PO's workload was too high this time around. So is there any danger in committing to zero story points but running the sprint as if it were a real sprint?

  • Good question, @david. There are two scrum teams with a shared PO and two new ScrumMasters. I am acting as a coach within our organization but am not part of the scrum team. Hope this helps clarify. – jmort253 Jul 11 '15 at 12:52
  • @david - we would have scheduled a refinement meeting, but we realized too late that this was more than he could handle. I would like answers to come from this at the "what should we do now" angle. This is our first sprint and we are all learning, so we surely aren't looking to assign blame, just fix a bump in the road without breaking scrum rules more than necessary. Hope this helps. – jmort253 Jul 11 '15 at 12:55
  • @david, oops, I just edited myself so your edit may have been wiped out. Feel free to suggest another if I missed anything, and thanks for helping to keep our site clean and build a professional resource! – jmort253 Jul 11 '15 at 13:02
6

From my experience, taking a week off and working on other things isn't usually too big of a problem. A lot of times that's when the developers get their own time to work on whatever pet project they have. Other times, it's around the Thanksgiving Holiday or the Christmas/New Years Holiday, so a large part of the team is out anyway.

What is your normal sprint length? If it's a week, then working a week sprint seems reasonable. If you normally have longer sprints, and want to run this one for a week, I might caution against that. Like you mentioned, there is a rhythm to a sprint. If you take a week off from sprinting, it's like you hit pause, then play again when you're back on. Changing the sprint length is more like changing what you're playing, or at least changing the temp of what you're playing.

Now, if you have week sprints, and there is technical debt to be worked on, that sounds like a good option. I would ask why you wouldn't follow the standard process though? What I mean by that is, write up the technical debt in terms of value for the development team (which of course has value to the end customer too, even if they can't see it as easily). If you treat the technical debt like stories, that will help to ensure the team is following all of their standard practices, and hopefully end up with quality results.

  • Hi Chris, this is literally our first two-week sprint we are about to complete. We are just getting started. Also, welcome to PMSE! Thanks for such a great first post. – jmort253 Jul 9 '15 at 18:49
2

Yes, I recommend another sprint

I am surprised that your Product Owner didn't want to do another sprint. Generally Product Owners tend to push the development teams to get releases out sooner rather than later. They are always up against external drivers such as launching at some trade event or beating a competitor to the market.

However, your gut feeling is in the right direction. Yes, you should do another sprint for the following reasons:

  1. To avoid the loss of rhythm, as you rightly mentioned.

  2. More importantly, by skipping a sprint you are sending the wrong message to the team about the importance of this project, deadlines and so on.

This sprint can be a mixture of:

  1. Resolving technical debt.

  2. Doing research work on priority stories that are likely to be scheduled in the coming sprints. This will give an opportunity for the development team to do the discovery or actually build a proof-of-concept so that they are in a better position to size the stories and minimize risk when they are actually scheduled.

Also, there is no need to make it zero points. If some work is being done it takes effort and that has story points associated with it. So, go ahead and put story points. On the research stories some people prefer to put a time box instead of story points.

  • I feel like #2 is a good suggestion for the team(s). They expressed interest in doing some research on some high value stories that would be coming up soon. As you said, this would keep the rhythm and also send the message that continuing to move forward is important, something that is considered very important in scrum. – jmort253 Jul 10 '15 at 7:45
2

I think it is also important to make sure the Product Owner understands that he also has commitments to the team. If he wants the team to commit to delivering planned features by the end of the sprint, he also need to commit to feeding the team with high quality input of the sprint - his requirement.

So I think the team could decide by themselves, depending on how much trust they have and how good the relationship is with the Product Owner, whether they want to go ahead and start a new sprint with technical research or whatever they want to do to use up the time, or just relax and enjoy life for one week. But anyway the next time they do retrospective meeting with the Product Owner, they need to have a serious discussion with the Product Owner how to make sure the team gets enough input even when the Product Owner in travelling.

  • Welcome to PMSE, Ethan! I agree on the input from the PO. I think it caught us by surprise. He didn't realize how much effort moving to another country would take. It sounds like the lesson we should take from this is to plan ahead for events like this and have extra backlog refinement meetings to help the team get more questions answered up front. Also, I will make sure the team is OK with my suggestion and doesn't feel like I am pushing it too hard, even if a break would violate scrum. I remember "there is the scrum way, and there is the reality." – jmort253 Jul 11 '15 at 11:27
1

TL;DR

In your specific case, it would be best to treat the week as a drag on productivity. This won't actually affect team velocity if you don't jigger with sprint lengths; what it will do is act as a visible cost in your project's release planning by reducing the number of full-length sprints remaining in your current schedule. This is a Good Thing™ because it reflects the project's reality.

The Red Herring

Is it okay to have a sprint where the team commits to zero story points?

Yes, but your real question is something different. :)

Make the Cost Visible

The product owner prefers the team not work on any product backlog items until he can groom the backlog further. We had planned to conduct a product backlog refinement meeting, but realised that the PO's workload was too high this time around. So is there any danger in committing to zero story points but running the sprint as if it were a real sprint?

While cadence is important to agile methodologies, the importance of transparency is often overlooked. The real issue here is that delaying work while the Product Owner is unavailable is a real cost to the project, and as such should be made visible.

With that in mind, I would tell the developers to use this week as work-related free time. Let them update their workstations, read a book on a new programming language they're interested in, or otherwise get paid to do something useful to them (and their future productivity) without formalizing it.

It is important not to make this a week of busy-work. Not only is that antithetical to the self-organizing principles of agile, it is simply not good for team morale. Busy-work also creates the illusion that the team is working on product value when in fact this time (while potentially useful to the developers) is explicitly a drag on the project as a whole. This central truth needs to be firmly maintained.

Technical Debt

On any project, there are non-product tasks that need attention. CI servers need updates, SCM servers need patches, and so forth. To the extent that these things affect the team, this is a good time to work on them, but the problem is that it becomes "invisible work" because it's not prioritized on the Product Backlog.

Additionally, the overhead involved in creating a one-week sprint rather than simply waiting until the PO is back in the saddle for the standard sprint length is probably not worth it. I believe it's better to capture this lost productivity as drag on the team's velocity, and simply plan better in the future.

Good Product Owners also generally keep a few "evergreen" stories and technical-debt stories on the backlog for just such occasions. Then, when nothing else is pressing, these stories can be legitimately worked on without being unaccounted for.

Why Team-Directed Sprints Aren't Kosher

Finally, the problem with a sprint designed and run by the team without the participation of the PO are legion. Consider some of the following:

  • Unless the PO has refined the backlog and is available for Sprint Planning, the chances of the team working on the correct Product Backlog Items or producing a useful increment are vastly reduced.
  • The PO has a pivotal role to play in defining the Sprint Goal for each sprint. That's hard to do without his participation.
  • The PO doesn't have to wait for the team to finish its artificial sprint. When he returns, he can unilaterally declare an Early Termination and a return to Sprint Planning, so any illusion of maintaining cadence is just that: an illusion.

Conclusion

The best thing to do is to turn your developers loose informally for the week. Let them work on whatever interests them, or on their professional development. While it may not advance the project directly, it will contribute to developer happiness and improve the overall effectiveness of the team in the long term, all without compromising the integrity of the Scrum process.

0

So I was going to suggest they do another sprint anyway but just focus on technical debt…

If you are talking about focusing on technical debt, it sounds like anticipating what the priorities will become in the product backlog. You might be right, or you might be wrong.

This may sound purist, but I would suggest selecting items from the top of the product backlog as it exists. Because product backlog refinement has been omitted during the lead up to that sprint, I expect the sprint planning meeting would be more challenging and time consuming, but that is just a natural consequence of how things have gone. It is "water under the bridge", so to speak.

Allow yourself to have a longer-than-usual sprint planning meeting, where you spend ample time sufficiently breaking down the top items. Be conservative in how many of the top product backlog items you put into the sprint backlog. Do what Scrum guides. The worst likely to happen is that the PO decides he would have re-prioritized the chosen items lower. At least you will have worked on what had been identified as the priority, as best as you could tell.

So is there any danger in committing to zero story points but running the sprint as if it were a real sprint?

I believe the danger is that you undertake work on technical debt that you assume will become necessary, and then find out that it was not necessary, or not in the way that you do it.

  • David, it is our first sprint but not our first line of code. We previously had no process. The teams were previously merged as one, and the product has been worked on by those developers for 4+ years. There is a lot of history in the code base. We simply switched from no process (or you might say one we made up) to using scrum. Hope this helps clarify. – jmort253 Jul 12 '15 at 8:03
  • @jmort, Yes, that is significant context. Thank you. Nevertheless, part of what I said would still be a concern to me... that working on technical debt still presumes something about what will be a priority. – David Jul 12 '15 at 8:25
  • The team does realize that adding things like a continuous integration server and refactoring some code to make it so they can start TDD or do some automation testing is important, and from their experience, they know where the "gotchas" are in the codebase and what's traditionally slowed them down. I did lump this in with "technical debt". I'm not sure that's the right term to use for things that slow the team down, but the result is the same. Adjusting the length of the meetings is good advice, and we did this with the backlog refinement before the first sprint. – jmort253 Jul 12 '15 at 10:20
0

When working as part of large teams (or when you have multiple teams on one code base) this can be known as a hardening sprint. Although you aren't driving down the outstanding points of the mvp per se, you are making things better overall.

You can undertake a number of tasks to improve things:

  • refactoring
  • reducing technical debt
  • improving test/code coverage
  • revisiting design decisions
  • updating wikis/designs etc
  • refining CI/CD

You would estimate these and work on a similar number of points to a normal sprint (assuming you've been logging these issues as stories).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.