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?

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
1
  • Thanks for your advice. I have since left this organisation and your question about the role is perfectly valid. I was a combination of BA and Scrum Master for a team without a PO. This made life very difficult and in a sense, I also tried to fulfill the PO role in terms of requirements and priority, in collaboration/negotiation with the stakeholders. It wasn't perfect but it did actually work. You advice however is spot on as as bug fixes and quick-wins are the work. Sprint goals where a challenge at first but we got better at them over time.
    – Spionred
    Aug 29, 2019 at 3:49
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.

Improve this answer
2
  • Thank for your feedback and I see your point about the impact on velocity only if these bugs and features dried up. Just wanted to point out though that I didn't use the word trivial. I don't consider any bugs as trivial and any "easy" feature that adds value is far from trivial. As far as being a captain, at least in the traditional sense, the team knows far more than I do of the product and the customers for me to get upset at anything they propose to work on. All I am trying to do is help them manage their workload and expectations of the customers of what can be and when.
    – Spionred
    Aug 29, 2019 at 3:43
  • 1
    @Spionred I mentioned the trivial because the tracking causes overhead. One of the greatest improvements adding git to my repertoire made was that I could make tiny commits because commiting was fast. Having to run every tiny thing through the prioritization process has a chilling effect on these tiny improvements. If people start to feel that it's not worth the hassle your codebase starts to rot because people won't work on anything unless it's big.
    – candied_orange
    Aug 29, 2019 at 5:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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