I’m going to write a series of posts on top tips based on experience and real projects of using IBM RTC for Disciplined Agility. It’s a bit of a brain dump, but here goes… they’re all tagged as rtc_tips if you want to read the whole set
So theoretically anything that the product owner wants goes on the backlog, but in RTC we tend to have other work item types like lessons learned, risks, etc. and it’s not always clear what should and shouldn’t be on the backlog.
I recommend using work item types such as:
Story – sized by points, used for Product Owner requirements
Objective – something you’ve got to do that will decrease you’re velocity (see below)
Defect – for bugs
Change Request – for changes
All of these I would configure as top level work items that I would expect as parents on the backlog. I use Objectives in a number of ways to deal with things that will reduce velocity (such as get a test environment ready). Of course it’s possible to phrase these as stories but that starts getting a bit silly, in a tool like RTC it’s far easier to read “Get Test Environment ready” rather than “As a customer I want the team to get a test environment ready so that I can have testing done without affecting the live system in a bad way”. I use them to act as a parent for work to do something such as mitigate a risk, improve team ways of working and other overhead activities. This means that overhead is explicit and honest, the Product Owner can see how much there is, what it is and discuss with the team if any of it can be reduced to improve velocity. “Hiding” these things as stories feels dishonest.
Naturally below all of these I’d then have task breakdown with time estimates. Tasks don’t belong on the Product Backlog but do exist on Sprint Plans.
I also configure RTC to manage a number of other work item types depending on the needs of the team:
Risk – no one ever delivered an important project successfully without managing risks
Impediments – raised at daily standups they should be resolved as quickly as possible, if that’s going to take longer than a morning then track them as work items, in distributed teams record them straight away.
Lessons Learned Capture them as you go
Milestone Not on the backlog but with dependencies on to Stories and Objectives which are you can then query for Milestones dependant on the current iteration, sorted by date, showing depends relationships. The team can then use high level milestones to communicate to external stakeholders in terms of progress towards major releases. A backlog full of detail is too complicated to give a headline summary, using Milestones is a good work around. I was interested to see this make it into RTC v3 formal project template as I’ve been doing it for a while in RTC v2. Milestones are especially useful as a point of integration between the dev project in RTC and higher level portfolio plans if you’re in that kind of environment.
So none of these latter work item types I would have on the backlog. I might create related objectives or stories to do something relevant to them but I wouldn’t directly put them on the backlog. For example a risk might have a mitigation strategy (objective) which involves some work (tasks) but once that objective has been done the risk may still exist. These things are all useful to manage and view separately from the detail and complexity of the backlog – also they just add noise when it comes to prioritising and gardening a detailed backlog.
Of course I would never follow these “rules” when they’re not practical. If there’s a risk that needs a simply investigatory task then I wouldn’t create an intermediary objective just to keep hierarchical rules perfect – that way leads to madness and the process police.