Unexpected items during sprints

Hi Mircea

Reserving a certain percentage of a Sprint is a gamble because, by definition, the demand for unplanned work is indeterminate. If you have a service level agreement with the Product Owner to reserve 20% for this purpose then I dare say it can be made to work, although you'll have to think about how to make it transparent.

A better option is for the PO and the Development Team to trade items in and out of sprint scope when waste (unplanned work) arises. The MoSCoWing (Must/Should/Could/Won't) of requirements can help here. If you can initially agree that no more than half of the requirements (as measured by story points for example) inducted into a sprint will be Musts, this gives you at least 50% contingency for such trading purposes. The Coulds, and if necessary the Shoulds, may be traded out. It's still a gamble of course, but "up to 50%" is better contingency than 20%. Obviously if less than 50% unplanned work actually does arise during the sprint, then the Should and Could have requirements may be progressed as per the Sprint Plan.

Whatever percentage you agree on for Must-Haves, it's important to make sure that the stated Sprint Goal depends on these associated mandatory requirements, and not on any Shoulds or Coulds. Failure to do this might result in the sprint being terminated by the PO on the grounds that the goal can no longer be met. In other words the Sprint Goal should be clearly aligned to the Minimum Viable Product for the planned increment of that sprint.

You are fortunate that it is your Product Owner who wants these issues to be addressed immediately. Often it's a third party, which can make things rather more awkward.

This discussion may be helpful - http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussion…

Thanks a lot!

Mircea,

As a Scrum Coach, I get asked this question all the time, so I created a chart to help people answer the question.

http://ScrumCrazy.com/bugs

Hi Ian,

I am continuously following your blogs and it is really helpful to get through all those scenarios we face while applying scrum.

I have one question: how we calculate sprint velocity of a sprint if any unplanned request comes in between sprint which is of utmost priority and we need to deliver it asap else it would lead to heavy loss to the customer on daily basis? It is 2 weeks of sprint duration in which team estimated 21 story points and all work is completed except last one of 5 story pointer in which is in progress. In this situation team has no choice and has to start working on unplanned request. 

Thanks for any clarification.

No change in calculation, you end with 16 story points for that sprint. You should remember about the reason why it was lower than usual during next retro and planning, and that's it.

Does that fast-tracked work add value to the product? Is it a Product Backlog Item which the Product Owner recently discovered, and which the Development Team agreed to action immediately instead of refining and planning it into a future Sprint?

Why not switch to Kanban and see how the team responds to the change requests/requirement churns from the Product owner?

In my opinion, as an exception to existing process/practices, unplanned work deemed critical by the PO may be presented to the Development Team for inclusion in the current sprint, provided the new item does not jeopardize the Sprint Goal and the Development Team is able to forecast completion of the item within the sprint.

it should be noted that there is increased risk associated with an unplanned item, and the Development Team may need to adjust their forecast to accommodate the new item.

From a Story Point/Velocity perspective, it is important to keep in mind that these items support planning, and therefore since unplanned work is not part of the "planning" process, I would propose relieving the Development Team from having to relatively estimate such items.   

They should still judge (gut feel) whether their forecast needs to be modified due to the new item, though.

I have once taken 2 members of the development team out of the development team and made them dedicated for maintenance. This way there was capacity to tackle incidents while the actual development team was not disturbed during the sprint. The members of this "maintenance team" cycled every sprint. When the maintenance team had idle time they tended to assist the development team with little things, even getting coffee for everyone.

I have once taken 2 members of the development team out of the development team and made them dedicated for maintenance.

Out of curiosity: What was your role on that team?

I have once taken 2 members of the development team out of the development team and made them dedicated for maintenance.

I like the idea of rotating 2 members as opposed to one. since that approach protects against a single point of failure, and promotes KT and cross-training.

To add to Julian's question, how large was the Development Team?

To All Experts here, need help!

Scenario- 

When business demands of some random tasks to be done for customers, which the Scrum Team is not aware of but one developer is, and the work gets directly fed into developer's list of tasks without involving the Scrum Team and the Scrum process. 

What would be the best possible approach that you as a Scrum Master would undertake to resolve such issue in future?

Why does the developer have a list of tasks to feed stuff into? Isn't there a Sprint Backlog which is owned by the whole Development Team?

Why doesn't the Product Owner order this new work on the Product Backlog...and what does he or she think about this mechanism being subverted?

Why does the developer accept this work in the first place, when he or she ought to be concentrating on the team plan for meeting the agreed and committed Sprint Goal?

As a Scrum Master I would get the Developer and Product Owner together and discuss all of the questions that @Ian Mitchell asked.  Coach them to arrive at the "right" answers to those questions.  SPOILER: the "right" answer is the Developer should be directing the people making these requests to the PO. 

Thanks @Ian and @Daniel for your suggestions.

There is a Sprint backlog but simultaneously there are some technical requirements which have been directly going to the developers (which ideally shouldn't happen).

I have noted your suggestions to begin with, the people mindset needs a change/coaching.

Thanks much for these valuable thoughts.