Skip to main content
Project Management

Return to Answer

deleted 8 characters in body
Source Link
Niels van Reijmersdal
Niels van Reijmersdal
  • 5.6k
  • 20
  • 32

I would create a card for it during the stand-up meeting and estimate it with the team. If its really 1 minute and it won't disturb the focus of the iteration do it, but don't disturb developers for it while they are working on something else. This also makes 'extra' work visible, this could be used later during the retrospective when Sprint goals are not met, certainly when its a lot of small changes.

If you have a lot of thesesimilar trivial changes I would groupgroup them into a somewhat larger one for the next iterationfor the next iteration. Question yourself do we really need it now? Because what might look like a small change, can be somewhat bigger when the developer actually starts on it. Make sure its time-boxed and postponed if it does take longer.

Keep in mind that small changes could have enormous impact on other disciplines in the SDLC. Simple example could be that a lot of automated tests need updating, or translations need to be applied. Read more about impact of small 5 minute code changes at Microsoft: https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/

I would create a card for it during the stand-up meeting and estimate it with the team. If its really 1 minute and it won't disturb the focus of the iteration do it, but don't disturb developers for it while they are working on something else. This also makes 'extra' work visible, this could be used later during the retrospective when Sprint goals are not met, certainly when its a lot of small changes.

If you have a lot of these trivial changes I would group them into a somewhat larger one for the next iteration. Question yourself do we really need it now? Because what might look like a small change, can be somewhat bigger when the developer actually starts on it. Make sure its time-boxed and postponed if it does take longer.

Keep in mind that small changes could have enormous impact on other disciplines in the SDLC. Simple example could be that a lot of automated tests need updating, or translations need to be applied. Read more about impact of small 5 minute code changes at Microsoft: https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/

I would create a card for it during the stand-up meeting and estimate it with the team. If its really 1 minute and it won't disturb the focus of the iteration do it, but don't disturb developers for it while they are working on something else. This also makes 'extra' work visible, this could be used later during the retrospective when Sprint goals are not met, certainly when its a lot of small changes.

If you have a lot of similar trivial changes I would group them into a somewhat larger one for the next iteration. Question yourself do we really need it now? Because what might look like a small change, can be somewhat bigger when the developer actually starts on it. Make sure its time-boxed and postponed if it does take longer.

Keep in mind that small changes could have enormous impact on other disciplines in the SDLC. Simple example could be that a lot of automated tests need updating, or translations need to be applied. Read more about impact of small 5 minute code changes at Microsoft: https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/

Source Link
Niels van Reijmersdal
Niels van Reijmersdal
  • 5.6k
  • 20
  • 32

I would create a card for it during the stand-up meeting and estimate it with the team. If its really 1 minute and it won't disturb the focus of the iteration do it, but don't disturb developers for it while they are working on something else. This also makes 'extra' work visible, this could be used later during the retrospective when Sprint goals are not met, certainly when its a lot of small changes.

If you have a lot of these trivial changes I would group them into a somewhat larger one for the next iteration. Question yourself do we really need it now? Because what might look like a small change, can be somewhat bigger when the developer actually starts on it. Make sure its time-boxed and postponed if it does take longer.

Keep in mind that small changes could have enormous impact on other disciplines in the SDLC. Simple example could be that a lot of automated tests need updating, or translations need to be applied. Read more about impact of small 5 minute code changes at Microsoft: https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/