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?

  • Why are they finding it harder to work on user stories? And why do you consider illness "interference" with the team? – Todd A. Jacobs Jul 29 '14 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 Jul 30 '14 at 7:19
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.

  • 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 Jul 30 '14 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 Jul 30 '14 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 Jul 31 '14 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.

  • 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 Jul 30 '14 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 PSM II CSP Jul 30 '14 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 Jul 30 '14 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 PSM II CSP Jul 30 '14 at 21:45

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.