The product backlog
In a nutshell, this is a prioritized and estimated list of features that the customer wants. Written in their own language. Estimated BY the people doing the work.(sometimes known as 'the team'..... not always in every organization though)
When I worked at a helpdesk, this was a support queue. A work order queue. Basically each ticket/work order was a backlog item. They were automatically prioritized by the order in which they were created. However, you can bet your hard earned dollars we also prioritized them on whether or not their systems were completely down or not (down hard). IN the end, the customer got to choose what the problem was, they got to choose when it was completed. We were only able to decide when we were going to commit to fixing it and come up ideas of tasks to do to complete it. When the ticket was closed, it was completed… we were “Done” and we moved on to the next ticket.
My first software job, the backlog was quite a bit less ‘rigid’ than the support queue. I came in for my first day and my boss pointed at his whiteboard. It was a collection of ‘things’ that needed done. Some were high level, some were tasks, very few were actually ‘software’ problems. For example: “Automate billing”, “create audit phone report”, ‘Create phone directory report”, “create eeoc report”, “create web service that exposes temp employee data”, “convert from old vendor software to new vendor software”, “refresh hardware”, “refresh ms office licenses”, “solve the IM client problem”. Anyhow, every month we’d meet and discuss the highest priorities and commit to an item. Every day we’d chat to eachother over IM and in person about our status and ‘swarm’ with the rest of the team for help. To me this was the ultimate ‘agile’ because it was goals and a cross functional team of people… the product was IT infrastructure for a staffing company.
My second software job, the backlog was very unclear. We had some specifications (written in that crummy “The system shall…” language). We also had use cases for all the same stuff! However, ‘everything must go!” was preferred over prioritizing. Generally whatever the fire drill for the day was, ended up being your targeted work. I didn’t know how to work in this type of environment without clear goals so eventually I wrote my own backlog out of the specifications and just started working a subsection of functionality. So I had backlog items that were in spec format “the system shall…” with very detailed test cases from the use cases JJ. (of course I’d call the ‘customer’ for clarification on stuff, which always turned into a 5 hour discussion because I had no focus or previous experience with this.)
What other options are there for a backlog?
Well you could just do line item requirements, right? Yes. They work ok as long as they are independently testable. It would be nice if they span the whole architecture too. In fact, if you’re familiar with RUP or Crystal clear, they talk about a prototype that spans the whole architecture early on in development. Crystal calls this the ‘walking skeleton’.
You could do use cases. I think they work pretty well actually because they’re self contained sets of functionality. However, in general I’ve never seen a use case that was ‘sized’ down appropriately for development. In general I’ve only ever seen them at a very high level. So the smaller the better!
User Stories: I find Mike Cohn’s user stories applied book especially helpful in ‘getting’ user stories. XP suggests user stories but Mike Cohn defines them appropriately as (INVEST) independent, negotiable ,valuable, estimable, small, and testable. User stories make great backlog items (dare I say the best backlog items out of anything I’m familiar with).
In the end once you have the list of ‘Things” and features the customer wants. Now the hard part starts. How do you estimate them? Well there’s a few ways:
Story points – these are relative point estimates. So if you have a functionality that is 2 points and you have another that is twice as big, it’s 4 points and so on. The points are made up by the team but some teams use ‘ideal team days’ to represent a point so that multiple teams can sync up on the same scale. Honestly, every team will have their own point system. The important thing is that everyone doing the work participates in estimating the size of it AND you estimate the whole size of the item, not just ‘your own little individual contribution to it’. One developer and tester I had constantly wanted to estimate ‘their involvement’ not the whole team’s involvement. This causes them to only see it from one side of things and makes your iteration plan worthless.
Hours – I’ve seen some success with this, but very little. Teams look at the backlog item, figure out all the tasks, and figure up an off the cuff estimate of the total hours it’s going to take. Honestly there’s a lot less science in this than relative point estimating because effectively you’re thinking back to similar experiences, then thinking back to how much of your time was spent on it. At least with relative estimating all you have to do is compare that item and it’s point value then come to your new item’s point value in relation to that one. Some people just can’t think in relative terms though and need to associate hours to it. I won’t ever understand why, but I can acknowledge that and move on J go ahead and use hours, maybe it’ll work for you and it’s better than doing relative points WRONGLY. J
Prioritize!!!
This backlog, to be healthy must be prioritized, estimated, and written in business language. Dang, sounds like a tall order. When and where do I prioritize and estimate at? A not so easy answer is “all the time, anywhere”. The most important thing is, involve everyone who is likely to do the work. James, what a cop-out.
Yea, I know so think about my examples above. My first software job, we just talked about priority during ‘sprint planning’ every month. For estimating, we’ve done some story writing workshops (I called them ongoing-planning meetings) and then we estimated the stories at a high level (t-shirt sizes: s, m, l, xl).
So, what would you have to do to establish a true product backlog in your organization: Business features in business language that are estimated and prioritized before you start a sprint!