This question is locked. New answers and comments are not allowed.
I'm wondering what the best approach is for handling routine code maintenance? What do we log our time against? How should we track? A story? A task on a story that we push through each sprint?
For auditing purposes, every check-in that happens in our repo needs to be associated to some sort of teampulse "item".
From the definitions I have read, and please correct me if I am mistaken, but it seems like a story doesn't fit the criteria for code maintenance work. (how would you write that story? "I am a developer, so my code needs to be formatted correctly so it is easy read"?)
By maintenance I mean any of the routine tasks that a developer will typically perform on a code base throughout the projects lifecycle that isn't impactful enough to warrant a story or bug, but should probably be noted / tracked so we can see how much time is being spent, on say, fixing other developers lazy formatting vs. completing stories.
thoughts?
For auditing purposes, every check-in that happens in our repo needs to be associated to some sort of teampulse "item".
From the definitions I have read, and please correct me if I am mistaken, but it seems like a story doesn't fit the criteria for code maintenance work. (how would you write that story? "I am a developer, so my code needs to be formatted correctly so it is easy read"?)
By maintenance I mean any of the routine tasks that a developer will typically perform on a code base throughout the projects lifecycle that isn't impactful enough to warrant a story or bug, but should probably be noted / tracked so we can see how much time is being spent, on say, fixing other developers lazy formatting vs. completing stories.
thoughts?
1 Answer, 1 is accepted
0
There is no single best practice on this. Basically you can do whatever feels best to you and your team. Even the Agile manifesto states that it is better to do whatever you feel is right in your context instead of blindly following some process ("Individuals and interactions over processes and tools").
For example some of Telerik teams do such maintenance as part of the ongoing stories. So when you are working on Feature X, you do the new stuff but also take a look at existing code and refactor as needed. We set aside some capacity for such work so that we know when not to spent too much time on work that has no direct business value. This allocation can be 10%-15% of the team's iteration capacity.
Other people do not follow the agile story definition as closely and create stories for such work. This allows them to track how much time is spent / or what part of the velocity is dedicated to maintenance work. Some teams here log bugs for such thing. In two words - great variety across different teams.
So sit down with your team and collectively decide how much time you want to spend on such tasks and how to handle them in TeamPulse - answering questions like "Do we need to explicitly track such work?", "Do we need to report how much time is spent on maintenance?" etc.
For example some of Telerik teams do such maintenance as part of the ongoing stories. So when you are working on Feature X, you do the new stuff but also take a look at existing code and refactor as needed. We set aside some capacity for such work so that we know when not to spent too much time on work that has no direct business value. This allocation can be 10%-15% of the team's iteration capacity.
Other people do not follow the agile story definition as closely and create stories for such work. This allows them to track how much time is spent / or what part of the velocity is dedicated to maintenance work. Some teams here log bugs for such thing. In two words - great variety across different teams.
So sit down with your team and collectively decide how much time you want to spend on such tasks and how to handle them in TeamPulse - answering questions like "Do we need to explicitly track such work?", "Do we need to report how much time is spent on maintenance?" etc.