Adding tasks to the backlog

Hi Hamish,
do you have a Sprint goal? If you do, it is OK to add items to the sprint backlog as long as the team can keep the focus on the sprint goal. If you don't, it happens easily that the team works event-driven on the things that come from production, and there is no real reason for you to do sprints at all. You can use Kanban instead to handle these issues. But if you value the advantages of incremental delivery of value, you may want to fix this by stating an explicit sprint goal and handle production issues in a way that doesn't affect this goal. Ask the team how they want to do this and which decisions are to be made for each production issue. This can result in a diagram like this:
http://www.scrumcrazy.com/One+way+to+handle+Bugs+and+Production+Support…

> For example, critical bugs in Production have come up that have needed to be addressed...

Who is performing triage on these defects? If it isn't the PO then he or she must at least be kept informed, as defects represent undone work. The PO needs to account for any impact this may have on the Product Backlog.

Some maybe naive questions, being ignorant of your exact situation:

If the defect only "recently" started to bloat the Sprint Backlog:
- perhaps you are creating Technical Debt in your development process?
- What does the Scrum Master say about these upcomings?
- Do you yourself have an idea what causes the problem? Have there been any recent changes in process, team membership, tools, ...?

Thanks for the replies, everyone. I'll go through and try and adress each point, and add the required info. Firstly though, up front, I am currently acting in the scrum master role. This happened by default by a certain extent, as the only trained scrum masters were the development team, but that was causing issues. I am the BA on the project, so it fell to me to take up the role, despite a lack of training. The devs support me in the required knowledge, and we've been using the retrospectives to help me get up to speed. Still, I'm hoping to get some training in the near future, but in the meantime, I'm trying to do what I can to upskill, hence using places like these forums to ask questions.

@Ludwig - We did have sprint goals at one stage, but we are adding such small and various incremental changes each sprint that trying to have one goal has been a bit of a problem. Still, it might be something we need to get better at. I've also put together an incident management process that looks very similar to what you linked to, so it would seem we are managing bugs in a fairly sensible fashion. The tracking of these other activities has been more about being able to show the business why we've fallen short in some sprints etc, as we can give a quantifiable response where necessary, e.g. "Well, we lost the exquivalent of 5 story points this sprint on dealing with the office move, then 4 more on people having to complete their performance reviews".

@Ian - As above, I have a incident management process that triages all the bugs etc, so I believe we have these well in hand. As a team though, we have a lot of others issues to deal with, for example, we lost half a day to infrastracture issues, so a story was added to reflect that. My thinking is that it's ok to track the effort taken on addressing some of these issues, even using story points, but I'm hesitant about adding things like that to the sprint itself.

@Another.com - The scrum master, me, is feeling that we're not tracking this work appropriately, and that's why I've come to these forums to get others viewpoints. As for tech debt, yes, that is something that we don't manage very well, and I believe we need to improve on. Unfortunately we have had very aggressive timelines to get the product into production, and as a result, we've cut corners. Everyone is aware of this, and I'm constantly trying to find ways to address this. As for what's causing the current problems, we are simply being impacted by a lot of external forces at the moment, that are beyond my power to intervene with. I already remove a lot of impediments as it is, but there are some things, as a scrum master, even I can't deal with. I just want to try and manage them appropriately.

> As a team though, we have a lot of others
> issues to deal with, for example, we lost half a
> day to infrastracture issues, so a story was
> added to reflect that.

You can account for infrastructure issues how you like, and it is reasonable to size them with story points if they help the Development Team estimate their remaining available budget for a sprint. The same can be done for housekeeping matters and for paying off technical debt.

However, it is up to the Product Owner to decide if this work represents value for the Product, and whether or not it should be represented on the Product Backlog. As such, the PO should be kept informed of any changes to sprint scope. Note that the Development Team can action this work regardless of whether or not the PO values it, since they wholly own their Sprint Backlog.

Hi Hamish,

as you have asked for personal opinions:

To me it sounds like you already are headed in the right direction: You are the Scrum Master, you know what your job is and you care for accomplishing your tasks. If "external forces beyond your power to intervene with" are causing the Scrum Team to create technical debt, I guess your best strategy regarding the external forces is to
- always expose the problem to management, the Scrum Team and perhaps also to some of the external forces
- further remove as much of the impediments as you can, taking one step after the other
- have more lot of staying power than the external forces.

Perhaps there are some more experienced forum members who can share some best-practice-tips with you.
Good luck!

Hamish,

Thought you might like this to help with your scope mgmt issues within the sprint:
http://ScrumCrazy.com/scope

Hope this helps!

Thanks for the feedback, everyone, it's given me some good points to consider.