The disconnect between business and IT. We’ve all heard about it and we’re all doing something about it, right? We’re embracing Agile, getting Lean and developing cross-functional teams in our bid to deliver valuable software to the people who actually need it.
But I’ve discovered a place where the business and IT don’t meet and I think it’s pretty important. It’s in the product backlog. More often than not this will be a spreadsheet or maybe an excellent tool like mingle (plug plug) with a list of stories in it. Stories are grouped by release and often by functional area too. But it’s pretty unlikely the business case for your project cares about functional areas. It’s got some goals. Maybe one, maybe more than one and with luck these have been quantified and prioritised and used in your planning and story writing.
And then ignored for the rest of the project.
The business value that agile teams are so keen to deliver lies inchoate in the product backlog. I would suggest you can get a idea of what a system is supposed to do from reading the business case. Can you get a good idea of the business case for your project from reading the backlog? There’s the disconnect.
Next time I’m building myself a backlog I’m going to add another property to my mingle story card template: Goal. Each item I put down in my backlog must explicitly reference one of the goals of the business case. During the inception phase it should be easy to report on what percentage of our scope is given over to satisfying Goal A and what percentage to Goal B. We can get an immediate validation on whether we’ve got our scoping right or have we come up with 100 stories about the least important (but technically most exciting?) feature we could develop. When we do release planning we can again get a quick indication of what the thrust of the release is from a business perspective.
A goal-centered backlog I believe would also give added impetus to employing user-centered design techniques on a project. If one of the goals of the application you are building is to save $500,000 per annum in training costs by having a simpler and easier to use application then the user research, information architecture work and interaction design activities necessary to make something “simpler and easier” need to be in the backlog somewhere. They may not end up as conventional stories but they do need to end up as something that gets done (which incidentally is how I define a story).
