1

currently shifting to SCRUM, we wonder what should be done exactly in the specific case :

Our analytics team need some script to be updated on the site we're managing. It occurs on a regular basis (possibly several times a month), but with no exact schedule, and they require this to be done "ASAP". This somewhat "emergency" wouldn't allow us to use the normal process for devs which would imply to have it in the product backlog in order to put in in the sprint backlog during sprint planning meeting. But this is not an incident neither and from what I understood incidents are the only tasks that should enter the sprint backlog during the sprint (we have a contingency for that). Shortenning the sprints wouldn't be an option neither as they're already only 2 weeks long and for most of the tasks this is very appropriate. What are our options ?

Thanks !

EDIT : I need to mention SCRUM is not an alternative here (or actually is the only one we can use). We're in a big corporation deploying agile methodologies and enforcing SCRUM. DevOps Teams using scrum are just the end of a End-to-End delivery model based on SAFe, with a whole process before an item makes it to the product backlog (which is defacto less AGILE than what it should, but as simple employees we don't get to choose, "empowered" is more a good intention than reality...). In other words, if the answer implies switching methodology, we can't really apply it, especially as SCRUM fits well for most of our tasks, only a few don't quite find their place in this model...

Improve this question
8
  • possible duplicate of Applying agile methodologies in a fast moving support environment
    – gnat
    Commented Jun 18, 2015 at 8:27
  • I editted the question. We're not as such in a "fast moving support environment", I even feel like it's the exact opposite (which is probably why management pushes SCRUM, convinced it will turn us into a spotify-like corporation...), but sometimes, some specific tasks, without being incidents, require a quicker intervention than most others.
    – Laurent S.
    Commented Jun 18, 2015 at 8:38
  • one of the answers in there explains how to do that with Scrum
    – gnat
    Commented Jun 18, 2015 at 8:42
  • confused by "current shifting to SCRUM..." AND "I need to mention SCRUM is not an alternative here". Huh?
    – Michael Durrant
    Commented Jun 18, 2015 at 9:28
  • 1
    You may also find programmers.stackexchange.com/q/271910/34069 useful. It is nearly, but not quite, a duplicate.
    – Michael Durrant
    Commented Jun 18, 2015 at 9:33

4 Answers 4

Reset to default
2

If you get more of those tasks, maybe KANBAN would be a better alternative, but you seem set for SCRUM, so lets see what you can do inside SCRUM:

SCRUM has a so-called impediment list. That's a list of all things that's keeping people from being productive. Such a task has not been planed in the sprint and doing it instead of working on the sprint goal is an impediment.

On the other hand, it seems that this indeed is a planned task. You could have a backlog item that says "handle requests from analytics" that you plan into every sprint.

Improve this answer
1
  • Thanks for your answer. KANBAN not being an alternative for us (management is still deploying Scrum to the whole company until end of the year, this being already quite messy I don't want to come with yet another methodology which isn't supported by management), your last proposition will probably be the way to go, by keeping some "spare time" in every sprint for support tasks, was it this one or others that might (will) come...
    – Laurent S.
    Commented Jun 18, 2015 at 9:43
4

We have a development and support mode of operation. We follow SCRUM. We have a similar environment where we may not be able to predict what cases/tickets will come during a sprint, so we have allocated 80% of our time in a sprint for development work and 20% for the support work during sprint planning.

When we commit during a sprint, we have some stretch user stories that we might take in case when we do not have enough support work during that particular sprint and we are done with our committed user stories. I believe similarly you can also have a stretch user story for the script in the sprint backlog and take it if it comes else continue with your development work.

I hope this approach helps you.

Improve this answer
1
  • Yep, "sapre time" seems to be the only way to go. I'm not worried about the "sprint backlog emptied before end of the sprint" though, first because product backlog should be refined enough to cover 2 sprints (so there are always items available if current sprint backlog is all done), and secondly because as a forme developer, I know how it goes, there are always things to do, especially as we're not talking about a lot of possibly "free time" at the sacale of a sprint...
    – Laurent S.
    Commented Jun 18, 2015 at 9:53
2

I've certainly experienced this in several agile settings.

I would suggest treating the 'rules' as guidelines which allow exceptions and changes from the normal process.

If these tickets are already well-sized, i.e. you know exactly what the work is AND you know their priority - apparently most important than I would allow these tickets to be paced directly into the ready column.

In order to complete tasks you will need to allow for this when sprint planning - either plan to have tasks that take up only 75% of the time available (not easy to do!) or allow for the fact that some tasks will not be completed when these 'asap' requests come in.

I'd also suggest that you look into using kanban which focused on a continuous flow of tickets and work rather than scrum which is focused on fixed length sprints.

Improve this answer
2
  • I just had a scrum training and indeed the guy often mentionned KANBAN, but I doubt I can even bring the subject on the table given the way things are moving here. Maybe that would be a good indication the company is doomed anyway, but i'll see this in the coming months and act accordingly. From all I read here and on other places, it seems keeping somehow some kind of "contingency time" is the only way to go... it just amazes me how much time you have to "spare" in scrum : for meetings, for contingencies, for backlog items refinements, ... hopefully there's some time left for dev :-)
    – Laurent S.
    Commented Jun 18, 2015 at 9:50
  • Yes it is often surprising how little time is left to 'dev' - but this can be good as it often exposes all the other crap that takes up time but isn't accounted for.
    – Michael Durrant
    Commented Jun 18, 2015 at 11:28
0
  • If those maintenance tasks happen without a predictable schedule, why not classify them as incidents? If all you have is a hammer, your task becomes a nail.
  • Alternatively, enter several tasks into your backlog labeled "examine the scripts and update as required." Pull one for each week of the sprint, close them when you've either changed the script or determined that no change is necessary.

But that's trying to fit square pegs into round holes. Are those script updates so much work that you need them tracked on the board? Each programmer should have some time to spare for things that need doing, without ticket.

Improve this answer

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.