Managing Technical Debt in Agile Teams
When a team reacts to an emergency, other work suffers, and quick and dirty changes cause a lot of technical debt.
Write down the best before date on those stories and make it plain that they are unique so you can manage them. If you use impact maps, put time constraints on higher-level impacts instead of individual stories. This will help prioritize impacts and manage entire groups of related stories. Small, easy wins always get prioritized over complex tasks.
Activity metrics are great for measuring whether the team is working well together, but they don’t show real progress.
Measuring progress with an activity creates the wrong set of incentives for prioritization. The delivery team wastes a lot of time tracking and managing unnecessary items—time that could have been invested more. Small, easy wins always get prioritized over complex tasks.
Activity metrics are great for measuring whether the team is working well together or not, but they can’t show real progress. Measuring progress with an activity creates a wrong set of incentives for prioritization.
The delivery team wastes a lot of time tracking and managing unnecessary items, time that could have been invested more wisely.
Managing all this information often puts a lot of strain on product managers, who need more time to deal with day-to-day activities. When market opportunities change, the business stakeholders face a severe dilemma.
Keeping the project would deliver outdated or useless features or delay work on something more significant. It’s straightforward to hide scope creep and unnecessary work in a pile of several dozen items.
The story card hell problem starts when a team only has one level of abstraction in their backlog — when the backlog becomes linear.
The numbers look precise, providing a false sense of accuracy and misleading people. The same applies to capacity planning, for example, using story points to calculate team velocity.
One good idea is to select several representative stories to reference and compare any new levels to them — for example, group stories into small, significant, and unknown.
Many teams use T-shirt sizes, which is also a good approach as long as the number of choices is limited. The Goldilocks approach also works — pull out stories that are ‘too big’ and ‘too small,’ and the rest will be ‘just right.’
Story prioritization is a classical trap for inexperienced product owners. Those who try to make all priority decisions find that prioritization takes too long and nobody is happy.
User stories should be small and provide some value, but a single story rarely delivers everything needed to complete a business goal.
Managing all this information often puts a lot of strain on product managers, who need more time to deal with day-to-day activities. When market opportunities change, the business stakeholders face a severe dilemma.
Keeping the plan would deliver outdated or useless features or delay work on something else. It’s straightforward to hide scope creep and unnecessary work in a pile of several dozen items.
The story card hell problem starts when a team only has one level of abstraction in their backlog—when the backlog becomes linear. The solution is to make the backlog hierarchical.
Once we populate the lower levels with more information, we only break down significant items into smaller ones.
