I’m all in favour of a good headline. So I read the blog ‘Why Scrum Backlogs Lead to Bad Product Decisions’, which I translated in my head into ‘Backlogs are Bad’. A contact sent it to me because he knows I’m a big advocate of good backlogs filled with epics and stories and stuff. It was a kind of a provocation.
Basically the author doesn’t like backlogs because he thinks people don’t do them very well. Instead he wants us all to keep track of requirements in a Googledoc, and the document should essentially be in the form of a series of marketing announcements.
It is increasingly clear to me that the requirements/backlog/stories used in an agile implementation that’s right for an early stage startup and the implementation you choose working in a big enterprise are going to be different. You will either want to have lots of requirements rigor and traceability, or you won’t care about that, or you’ll be somewhere in between. The degree of requirements formality will depend on such things as:
- the degree of certainty regarding what you’re building
- the size of the team
- the maturity of the team
- the nature of the industry (a social media app is different from an air traffic control system)
If you are working with superstar developers who all actually know how to and want to work as a real ‘team’, and the nature of the project allows for it, then the need for formal requirements is going to be less. But that’s not most projects. And the reality is that agile is kicking at the door of the big enterprise people, who have lots of process, and they need formality. There’s already a ‘trust’ question around agile in the enterprise. Dumping the business requirements specification in favor of a Googledoc filled with marketing announcements is not going to fly for these guys. It makes me feel edgy, because lots of stuff that needs to be done is of absolutely no interest to end-users. It’s background work. It’s dependency stuff to get the cool stuff to work.
And yet, and yet… maybe there’s something in it. In certain situations. Actually maybe it’s a good idea, and I can actually use it now! It happens that I’ve just started working on stage two of a project where the goals are vague and the stakeholders are vaguer. I mean, we’re not going to be building any production ready code, we’re going to be doing some light prototyping to figure out if we’re going in the right direction. You know, that could save me a lot of work. It makes no sense to be super precise if I can’t be accurate.
Hey guys, you know what we need to do? Let’s just build a website that announces all the cool features that people are going to get, and that way we can figure out what our big, life changing, industry disrupting vision of this app is going to be. Then if they go for it, we just build it.
If that’s the way we go, and people see things the way we do – well, then I’ll probably make a backlog and fill it up with stories. Or maybe not.
Note to self – there are different ways of doing things.
This article first appeared here.