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?