Shane DrummDigital Product Person| Journey OnePerth, Australia
How do people practice scrum when working in a small team that creates features but is also supporting the product and have to do unplanned support tasks. How can I protect my burndown chart? Saving Changes...
Sort By:
Eric SimmsSenior Program ManagerBaltimore, Maryland, United States
You'd can't protect your burndown chart in that situation. A Scrum team is supposed to be insulated from outside interference such as performing support tasks; each support task you do robs you of time available do work on your sprint.
I'm in a similar situation, where my team does development work and support tasks. I have to make my Management understand that every support task we do detracts from our ability to do development work. They don't want to hear that, but that's the reality of the situation. When we receive support work I promptly let Management and customers know how much it will lessen our ability to produce development work; that's the best I can do under the circumstances. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Rather than protect it, showcase it. Rather than protect the protect the burdown, the SM should protect the team. Transparency! I&A!
Ideally, there should be no unplanned support tasks. Those items go into the backlog and pulled into the sprint backlog as needed based on priority. As the team(s) mature with story writing, execution, testing (and automated), CICD, support tasks should decrease dramatically. Saving Changes...
Eric SimmsSenior Program ManagerBaltimore, Maryland, United States
Shane,
After reading Andrew's reply I realize I might have misinterpreted your initial question. I assumed the support tasks you mentioned were external to your development activities, such as helping out when an application unexpectedly goes down). Is this the case, or are the support activities you perform part of your development activities? Saving Changes...
If this support work relates to the product and the team is 100% dedicated to that product, then their backlog should include both development and support work items. You'd likely have a product backlog which might only reflect the development work items.
The team's burndown chart would show the progress in completing all work items whereas a product burndown/burnup chart or version report (a la JIRA) would be focused only on the development work items.
It's reflected like any other item associated with the product, in the backlog. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The problem with that situations is do not take into account that develop must be manage in a separete way than maintenance. Both are totally different process and not matter the approach you use. What I mean is not physical separation or team separation. What I mean is to manage them two different process (or things inside the process) must be taken into account. Saving Changes...
"If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time--a tremendous whack."
