1

I have introduced sprint into our team and after a rocky start, we are starting to get some rhythm. One of the opinions of the dev team is they still want to be able to work on bugs and enhancements requests that are "easy" to do as this makes our customers (internal to our organisation) happy. After all, that's the end game, right?

Anyhow, my stance has been that its ok to do it so long as it does not impact on the committed sprint. If it does we have to asses the priority and add it to the next sprint at the earliest. This has worked really well however I am starting to think this it's the not the best option from a planning perspective.

The problem is that I have asked them to add the story for the new work into the sprint and size it, therefore growing the number of points in a sprint.

My concern is that I am going to introduce 3 monthly planning next year when we will use the velocity of the last 5 sprints to plan for the number of sized stories we can commit to over the next 10-12 weeks (i.e. velocity * 5-6 2-week sprints)

Am I creating a false economy (velocity) by allowing the developers to add and size stories in a sprint for bugs and "easy" enhancements? or is this the way to go?

4

You sound like a captain upset that your rowers are taking time to bail the water out of your leaky boat. Bailing isn't going to get you where you want to go. But ignoring bailing can send you to the bottom.

The simple fact is your team needs to do some bailing. They also need to take lunch breaks. Go home and see their families. And once in a while sleep. The real question is, does tracking any of that in a sprint help?

Sprint planing doesn't have to be the sole arbiter of credit people receive for their work. If it's not you can save everyone a lot of noise by keeping that work out of planning. Fixing trivial bugs and adding trivial features can be ignored in the sprint as much as bathroom breaks.

You're concerned that it will impact velocity measurements. Well it might if the trivial bugs and features suddenly dried up or doubled. But understand that with only one team and only 3 months of data velocity is going to be extremely fuzzy. Regardless of how much trivial work is minimized velocity isn't going to do much yet besides make the team more conservative about how much they predict they can accomplish in a given sprint. That right there is the best use of it.

If you want this work tracked then you absolutely need to allow developers to add and size stories for "easy" bugs and enhancements. I wouldn't recommend taking this away from them. I would encourage prioritizing tasks and doing the harder stuff first.

0

You say you're mostly concerned with the impact of these small things on your ability to estimate. Here's the thing, though: bugfixes and small feature "quick-wins" are work. They calculate into your velocity. You should spec and estimate them (with story points or whatever you're doing) so you can factor them into your velocity data. In other words, they're not a distraction from the work, they ARE work.

You haven't said what role you fill on the Scrum Team, but you sound like a Scrum Master. The question I have for you is: What does your Product Owner say about this? It's their call. Even during the sprint, it's entirely up to your PO to say whether they'll prioritize these things incoming things high enough to suggest inserting them in the sprint, and the Development Team's accountability to say whether they're going to negotiate them into the sprint plan. If someone brings this kind of thing directly to a developer, they need to be redirected to the Product Owner.

A sprint plan isn't a commitment, it's a forecast. Nothing's locked in stone (or even "committed-to") about a sprint plan. The sprint plan represents the work that the team forecasts it can do to accomplish the Sprint Goal that they crafted during Planning.

You ARE crafting Sprint Goals for each sprint, right? You might consider adding something like "...while keeping customers delighted with our responsive care of their needs.", so that these sorts of things aren't completely left-field out-of-goal tasks.

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.