0

The Scrum team I'm currently working with are finding it harder and harder to work on user stories that have been forecast, so I've been looking into Sprint Interference charts.

How do I take holiday/sickness etc into consideration? Should I track that separately or just treat it as interference or something else?

Improve this question
2
  • Why are they finding it harder to work on user stories? And why do you consider illness "interference" with the team?
    – Todd A. Jacobs ♦
    Commented Jul 29, 2014 at 21:59
  • I'd love to be able to remove the impediments, but unfortunately they are beyond our control. I simply want to track the impact as there's not much else I can do. I don't consider it interference, but this appears to be used to help track capacity so wondered if they should be combined. Are you saying I should track holiday/illness separately and then combine the data for capacity planning?
    – MattDuFeu
    Commented Jul 30, 2014 at 7:19

2 Answers 2

Reset to default
1

This seems to be a few different questions.

1. How do I take into account holidays?

With teams I encourage them to use their velocity as one of many things to reference when planning the next sprint, not a hard and fast rule. Lets say we have a team of 5 members with a velocity of 20, if one of the team are off for the next sprint I would suggest aiming for around 16 points. Of course, this could be much higher or lower depending on the individual pieces of work, and the team circumstances.

2. How do I plan for unexpected interruptions?

This is where the velocity is really useful. If you find the team are delivery as much as expected and everyone is happy with the output you don't really need to worry about these interruptions - they are absorbed into your velocity and vaguely consistent between sprints. On the other hand, if the teams velocity is dropping (or has a lot of variation caused by interruptions), the customer is not happy with the team output, or the team are not happy with the amount of interruptions, it sounds like you need to focus on reducing these interruptions. Something I have done in the past is create a separate 'task board' where team members make a note of all non sprint related work. This creates visibility of all their interruptions, giving you empirical evidence to use to focus on the reducing these. Often, a few people are identified as the main 'time bandits', and having a chat with them explaining why they should come to the Scrum Master rather than developers directly can help with this. Sickness can be identified here, but not really planned around.

Improve this answer
3
  • As I mentioned, the interuption remaining are out of our control, so can't be reduced. I like the sound of the separate task board. I'm currently tracking the other tasks, but this will definitely raise visibility of the issues upwards.
    – MattDuFeu
    Commented Jul 30, 2014 at 15:01
  • Having read this through a few more times, you've helped me realize I'm looking for "one chart to rule them all" which doesn't exist. I'll add another tab to my spreadsheet :)
    – MattDuFeu
    Commented Jul 30, 2014 at 20:16
  • The nature of interruptions are they are generally out of your control - the key thing is recognising the impact they have had on your committed work. It's a lot easier to explain that something isn't done on time because you spent 3 days saving the world (and other recognised high importance tasks), than it is because 'some other stuff came up'.
    – SpoonerNZ
    Commented Jul 31, 2014 at 11:14
0

I get this question quite a lot, usually from newly formed scrum teams. My answer is always the same: Don't worry about it.

There are so many things can interfere with a sprint that it's impossible to calculate. Just let things settle and trust in your velocity.

One final thought: You describe a situation where the scrum team are finding it harder and harder to work on user stories. I'd hope that this is being discussed at the sprint retrospective and changes made, ie: Take in less for the next sprint.

Improve this answer
4
  • Unfortunately we have a fixed time scale, so although you're right and things will settle down, I would like some evidence of the issues we've struggled with. And yes, we're trying to plan around them, but thanks for the pointer.
    – MattDuFeu
    Commented Jul 30, 2014 at 15:03
  • Why do you need evidence of issues? What value will it provide? Issues that occur in the sprint should be addressed asap, but in any case, at the sprint retrospective. It's for the team to decide how to handle them, with some possible coaching / mentoring / advice from the scrum master.
    – Derek Davidson PST CST
    Commented Jul 30, 2014 at 17:38
  • These issues are out of our control, so can't be reduced. The main reasons I want them are for upwards reporting, analyzing (so I can hopefully show the people that might be able to do something about it what would have the largest impact/ROI) and capacity planning. Either way, I'm worried this has gone off topic and I've failed to explain things. I really don't see how I can not worry about them. At the end of our fixed time I can't report upwards "not sure what wrong". Sorry for the confusion.
    – MattDuFeu
    Commented Jul 30, 2014 at 20:15
  • 1
    I was trying to dig down to the fundamental problem you were facing and I think we have it: Scrum requires that a scrum team possess all the skills necessary to create the product they are asked to create. It sounds like you don't have that. My approach would be to raise this as a major impediment and log all related issues as they come up (especially at the sprint retrospective). As scrum master, the task is clear. You need to resolve the fundamental impediment.
    – Derek Davidson PST CST
    Commented Jul 30, 2014 at 21:45

Your Answer

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

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