I have been throwing "things that team will do later" (TTWDL) into the product backlog along with product functionality to be implemented. Needless to say it is now long and full of bugs/ tasks from previous sprints. I can't figure a different place to keep track of open items from previous sprints.
I read the following two posts and am in no better spot:
How can I keep track of open bugs/tasks from previous sprints separate from product backlog items related to new functionality?
I think you have the right place. ie the backlog. But only if you are actually going to do them and they should be at the TOP!
If you aren't going to do them, I suggest a 'will not fix' or 'phase 2' dumping ground column/tag/board but don't kid yourself that they will somehow be picked up and done magically without taking up time you want spent doing other features
TL;DR: On the top of the product backlog.
Sounds like your tasks are not DoneDone. Completely finish and make features production ready before picking up any new features.
You don't want to reserve time later to make it release ready, because how much time you need is uncertain, but more important context switching is expensive. Fixing or finishing tasks later will consume much more time then doing it now, because everything is still fresh in memory.
Handling defects
I suggest you implement a zero-defect policy, see this answer for more details: https://pm.stackexchange.com/a/19805/8528
Promote product readiness:
There is a saying in XP that production starts on day one of the project. From the first day you write a line of code, you treat the project as if it were in production, and after that, you are merely making changes to a live system.
It’s a profound difference in how you view your code. Instead of viewing production and deployment as some event way off in the distant future, you imagine you and your team are in production today and start behaving accordingly.
Doing this has the following advantages:
- Team respects the code base - leading to higher quality.
- It’s easier to make changes - as a result of well refactored code.
- Pride of ownership goes up - because team is doing quality work.
- You can release at any moment - which is the only time we add value.
How can I keep track of open bugs/tasks from previous sprints separate from product backlog items related to new functionality?
You shouldn't even try! One of the purposes of the Product Backlog is to act as a parking lot for things related to the project that may never be reached during the project lifecycle, but that should be captured.
By keeping the information, you avoid entering duplicates, and can also provide estimates of project run-time with or without features in your parking lot. This can be useful for project planning, up to a point.
You should generally only prioritize fine-grained stories for one or two Sprints ahead. The rest of your backlog should be left alone as YAGNI items until they are actually needed.
On the other hand, if you have items that you know will never be done no matter how long the project runs, you should simply discard them as clutter. If the issues are important, they will be re-raised by the team or the stakeholders; otherwise, if no one cares about those particular Product Backlog Items, why continue to track them?
If you just can't bring yourself to discard anything, even if it's causing you friction in your process, then archive the items. If you're using Trello, archive the cards or move them to a Parking Lot list. If you're using Excel, move the items to parking_lot.xlsx. If you're using something else, you get the general idea: items that will never be done, but that isn't thrown away, are filed away where no one has to look at them during Backlog Refinement or Sprint Planning.
My personal rule of thumb is that if a user story reaches "we're never going to do it" status, I throw it away. The "maybe someday" stuff just settles to the bottom of the Product Backlog, like sediment in a pond.
Bugs shouldn't be kept separate from the other tasks in a backlog. If they are, then how is the Product Owner (I'm assuming that, as you mentioned 'sprints', you're doing Scrum) going to prioritize them? If you've got the following in terms of most-important to least important:
Story A, Bug/Task 1, Story B, Bug/Task 2
Then how on earth are you going to signify that while keeping stories and bugs in separate places?
That being said, what you can do is find some way to delineate bugs separately from stories - many issue tracking systems will have this functionality built-in, allowing you to easily filter through them to view only that in which you are currently interested. Failing that (if you're using, say, Microsoft Word or even just a bunch of printed pieces of paper (please no)), you can simply mark them as a different colour.
"things that team will do later" (TTWDL) ... bugs/ tasks from previous sprints. . . . open items from previous sprints.
I'm interested in what these items are.
If they're new work that you just didn't get to (eg, you descoped the sprint to finish within the timebox), then they definitely go back on the product backlog to be reprioritized later.
If they're items that were dinged against your acceptance criteria, I call those liens. I put them back in the product backlog, but tagged accordingly so that status is visible when we're prioritizing.
If they're cleanup tasks, to bring the code quality up to production standard now that you have an initial implementation, then the first thing I ask is, what's your Definition of Done? Does it include production quality elements (tests, documentation, responses to code review items, etc)? If not, then it should, and you need to include that when figuring how much scope you can get done in your timebox (or vice versa).
That aside, my team tends to put items like this in the technical debt pile, with the understanding that they'll be worked between sprints or as able, and the expectation that we may sometimes do a sprint whose goal is to reduce the technical debt.
If they're things that came up as additional good ideas during the sprint, definitely the product backlog.
If they're bugs that were discovered after the sprint was completed, then you might or might not have a separate process for handling bugs. If you don't, put 'em on the backlog, tagged as bugs and/or known issues so that is visible when prioritizing. You might sometime have a sprint whose goal is "squash bugs".
