We've moved our group's workflow to a scrum-based approach, with a lot of success. We're getting things done, people are more engaged, and we're more focused on our actual user community's needs.

Because we needed to work on processes over tools, we're using physical cards on a backlog board and a task board. This works pretty well, although we're probably going to move to an electronic version eventually as we're starting to get more remote team members.

This works very well for "right sized" user stories. But how do we deal with things that are really too small for a user story? Sometimes these are bugs/defects, or sometimes they're just really small feature requests or enhancements. For example, our Gitorious installation appends a superfluous s to repository names when one makes a clone. It'd be nicer if it didn't.

One could write user stories for every thing like this (which is what we do), but a) it feels overweight and not at all "agile" and b) such stories inevitably get scheduled below bigger, more important things, even though they're often low-hanging fruit (small effort for small but noticeable results).

Or, one could have a separate issue tracker. However, that suddenly goes from one place to look for work — the scrum task board — to having two tools. Is there a good way to integrate these things so they don't act in opposition to each other?

Or, one could just leave these things out of the process and shout them at each other across the room. There's a serious risk of this becoming the de facto process if I don't fix this. When this works, it's basically fine, but it's problematic because a) it can disrupt productivity when people get distracted from their other work by unscheduled interruptions and b) when these issues aren't immediately fixed, they can (as the question title) get dropped.

6 Answers 6


We have an index card on our board, that permanently sits in the Backlog, labelled "Technical Debt". Any team member can grab a post-it note and write down T.D. they think we are collecting. For example, if they know that a coding decision could have complications later down the line, we stick it on the Technical Debt card.

At the beginning of every sprint we review all of the post-it notes accumulated. If we feel that there is some debt we can clear in the new sprint, and it is not in itself a proper story, we add those as Chores. We also double-check if any of the Debt collected will impact the stories to be worked on in the sprint.

Quite often some of the "little things" that you mentioned end up in the T.D. section. We tend to knock out a handful of them in each sprint just to make sure we are keeping on top of things. We don't assign points to them (since they are Chores, not Stories), but large pieces of work are avoided unless absolutely critical.

Personally, I prefer using post-it notes. It is more tactile and interactive than a software tool (although I do maintain a spreadsheet for my own sanity). The team tend to shuffle through them out of curiosity when they are at the board. I doubt they would take the time to browse a software tool at their desks.

  • 4
    Just out of curiosity, how did you convince your product owner to let you work on collected technical debt rather than user stories? Ours always forbade us to work on them. He wasn't right, but I'd like to know how to approach a PO with an issue like this.
    – Zsolt
    Commented Feb 15, 2012 at 15:34
  • 3
    @Zsolt - On my current project I raised the issue right at the beginning. I explained how Tech Debt can snowball into a maintenance nightmare or even derail a project that everyone thought was going well. Since Agile is focused delivering quality, and the team is empowered to achieve this, I haven't had too much pushback on it yet. Obviously there is a balance to be made. If you try to tackle too much Tech Debt in one sprint the PO will feel that nothing tangible is getting done. For particularly large T.D. I work with the PO to try and incorporate it into proper Stories, if possible.
    – Ben K
    Commented Feb 16, 2012 at 9:20

You say you need to work on processes over tools. Generally with successful Scrum, the individuals and interactions are even more important than the processes and the tools, so if the team are just calling out bugs to each other, and that's working, why not carry on doing it?

At the moment, the lightweight nature of the interactions is probably giving you a lot of benefits - at a guess, perhaps the speed of response, the feeling of being part of a team, and the fact that it's not written down so it has to be fixed before people forget.

Given the benefits, what are you hoping that the processes will give you? Are you looking to track quality (remembering that the lightweight communication is helping to improve it anyway)? Who for, and what are they really interested in? Who cares about the little things being tracked?

Or are the little things actually being dropped? If so, have you communicated the impact to the team, and asked them to come up with solutions? They might actually consider having two tools or a bit more heavy-weight documentation worth putting up with for higher quality - but you won't know unless you ask the guys on the ground, and they'll know what the balance is better than anyone here.

  • Yes, little things are actually being dropped. Plus, my boss is living in a constant state of anxiety, and feels like he needs to micro-manage. Right now, the team can't point to anything to assure him there's no problem, even if the fact is that the perception is worse than the reality.
    – mattdm
    Commented Feb 14, 2012 at 18:07
  • I'd ask the boss what he needs to see to be reassured, then, and tell the team to provide that reassurance. They'll come up with a way.
    – Lunivore
    Commented Feb 15, 2012 at 9:40

It's all about choosing priorities and visualizing your work.

Your scrum board doesn't have to be restricted to sized stories only. And, please, don't try to size non business value work. Many forget that the velocity is meant to measure the "business value" being delivered from the product backlog.

This means that it is limited by all the other "stuff" or "overhead". But that doesn't mean that when it comes down to prioritizing the work that you don't merge ALL lists of work.

One team I have worked with chooses to fix a few bugs in-between each story. These are on our board, stack-ranked, but unsized. Our PO prioritizes them along with the stories. We then watch our bug trends to measure if we are keeping up or knocking down our tech debt at a desired rate, while delivering the user stories.

While we do have a post it note board, we also use Rally, which allows us to have a Prioritized Backlog and Prioritized defect list, it allows us to merge these into one Sprint Backlog during planning. We also include other "little things" like missing unit tests or CI. We have another set of working agreements when a "severity 1" issue needs to be taken care of during the sprint as well. It also goes on the board.

ANything we want to see, goes on the board and is prioritized. Its great for everyone because we aren't in any sort of constant conflict between tech debt and business user stories. We balance them every sprint with the help of our PO and we learn a lot about how we manage all our work.


I think Lunivore and durzagott give some great advice. The Technical Debt tracking is very smart. If something doesn't rate more than a 1, you don't really need to over plan.

A couple of thoughts to build on what they said (go read their posts if you haven't yet).

1- What is your Business Value? You mention how many of these things are low priority. One thing I've noticed is sometimes in our focus on user value we forget user cost. When assigning value to a bug, it's not about what it will give the user, it's about what will the impact be to the user if they encounter this. This is anti-value and needs to be factored.

2- Never load up 100%. Many agilists promote this concept. Don't let your teams pile on so many stories they have no flexibility. Something will go wrong, it always does. Leave some un-tasked time in the sprint to handle these spikes.

3- Fix now vs Fix Later: The ScrumShortcut blog has a really good post on this. The concept is that if you find an issue before the story is marked "Done" then fix it right then. It's part of the acceptance criteria for the story and it's not done until fixed. If the bug is found after the sprint, then you schedule it to the backlog (durzagott's idea of the Tech Debt area works great here.)


Club them(such stories/tasks) together to form a lump which suits your team, according to relevant functional areas Then relate & prioritize them according to business value.

This would require a lot of technical insight and an ability from the tech guys to advocate & convince business/PO that these stories ( e.g. long term tech debt , ability to automate more where required , need to write unit tests , performance tweaks etc) really do carry business weight.


A scrum is to my point of view a theoretical model to be adapted in your own precise situation. You have guidelines to follow, rules and responsabilities like the scrum master for example; but you can change them is your team thinks it would work better another way. I would keep it simple; have a meeting with your co-wokers and settle yourself what is the best way for you to organize your daily work procedures: what to keep or what you change in that model. Invent something that fit perfectly to who you are and what you are doing. I am sure that you all have great ideas. Just share them with each others. You will see your motivation and your quality of life at your work place increase a lot. You will have great fun innovating. I think that the goal of any management model is to be adapted to a precise work environment. I your question, I deducted that the Scrum model do not apply perfectly.

  • I did not mean to stop what you are doing; but it is one of my personal issue that people have all they need inside their team to create, adapt and innovate; they just have to share and decide. You are certainly doing a great job. Commented Feb 15, 2012 at 12:52
  • 1
    Let's say, for the sake of argument, that we don't have particularly great ideas in this case, or that we have various ideas but are uncertain of them. We decided, hey, we could ask about this on Stack Exchange and maybe get some helpful suggestions from people who have been in similar situations. Your answer sounds very pretty but doesn't actually address the question even a little bit.
    – mattdm
    Commented Feb 15, 2012 at 20:22
  • I went on the web to understand better how a scrum works and honesly I do not like it. But maybe having a model to implement like a scrum is, helps people organize themselves better and adapt that model to their precise situation. Commented Feb 21, 2012 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.