A little while ago in a private Agile forum I saw a post by a person who was very frustrated with Agile.
Their main concern was over the manifesto value “Working software over comprehensive documentation”. The scenario that they presented was one, where as a Product Owner, they wanted to understand a few of the business rules that the product had within it. They were informed by the product development team that they would need to create a user story for it, prioritise it against the backlog and when it hit the top of the queue it would get done.
Now the Product Owner chose to put it midway through the queue, but they were still unhappy with the fact that given the team’s backlog it would mean they would get their answer to what they felt was a simple question in two months time.
Why can’t I have just some documentation so that I don’t have to wait two months to get an answer on this? If we were still using waterfall we would have the answer right now.
A few people responded that Agile doesn’t mean no documentation, that there is often the documentation that is needed, but obviously this was one of the rare cases that the needs were greater than normal.
My thoughts on the problem raised were almost completely different:
- By not spending time documenting everything the team would have saved time over a prolonged period. If the team had spent time documenting everything to the nth detail then it might have taken a total of two or three months additional effort, for something to only be requested once. Now think about how much extra development work, actual beneficial changes to the customer, that they would have delivered in that time.
- The Product Owner chose to prioritise this knowledge below half of the outstanding work. It was always in their power to make it the highest priority item if they wanted to.
- There is a bigger issue that is being ingored or overlooked – the fact that the team had a four month backlog. I am not saying that a four month backlog is wrong, I am saying that a four month backlog is worthy of investigation to see why it is so long and whether something can be done about the constraints in the system to lower it. Think about how the team may feel knowing that there is four months of work hanging over their heads. They are unlikely to feel inclined to innovate knowing that there is so much that the product owner still wants delivered.
Do you think if the backlog was only a week long that the original forum poster would have made a comment about the Agile manifesto not working? Of course not, they would have waited only a week to find out that information and the team would have been considered responsive in their eyes.
Agile Forest 
Congruent with my “no product backlog” post a while back š
There a few key takeaways here for me:
1) The Product Owner isn’t familiar with the business rules for the product that they own. That’s a potentially catastrophic situation – they are making key decisions about something that they don’t understand! Understanding business rules and requirements is the Product Owner’s job – if they need to document things for their own understanding, they should.
(This is one of the many reasons that BAs should be considered to be an extension of the product owner, not part of the development team – or even IT)
2) It can’t be that important if they’ve put it that far down the backlog.
3) Sounds like a great opportunity to explain the benefits of executable specifications and human-readable tests – both to the Product Owner and the development team.
4) This actually demonstrates the power of a longer backlog – it helps defer low priority busywork. (And there isn’t anything _wrong_ with a long backlog anyway, as long as it is reviewed regularly and not treated as a simple FIFO queue)
Great points Robert.
Agree with points 1-3. But not 4 š A long backlog is a huge admin overhead for a product owner, often to the point where it becomes useless. And why would you “defer low priority busy work”? If it’s low priority busy work it shouldn’t be done at all! If it ever becomes important then it will be done because… well, it’s now important!
Please read my blog post on this for more info on my views š
http://neilkillick.com/2012/07/26/product-backlog-an-agile-anti-pattern/
Depends on what’s in your backlog. If your backlog consists of fully-specced ready-to-implement stories, then yes, that becomes a problem. If the backlog consists of very lightweight stories (probably of epic size), then it shouldn’t be that hard to manage.
Without a backlog, though, there isn’t anyway to determine if you’re working on the most important things. It’s not enough to say “This is important to work on” – you need to be able to say “This set of things are more important than that set of things, so we work on those first”. (It’s assumed that both sets are important).
The question seems to me to be “How should we _manage_ the backlog?”. The way I encourage my project managers to manage the backlog is exactly the way you describe – using a roadmap that evolves. It’s still a backlog, though – a set of features in the pipeline to be implemented that we are not working on yet.
If your backlog consists of a lot of little features that need to be evaluated with regular workshops, then you’re doing it wrong.
I totally get where you’re coming from but again I partially disagree (this time with your 2nd paragraph). Surely “the most important thing” rises to the surface? To say we need a backlog to determine the most important thing to do next is like saying we need a To-Do list to ensure we are doing the most important things in our lives.
I have spoken to product owners who have simply given up with their backlog because of it size. And I’m not talking about fully fleshed out stories with specs, I’m talking about cards on a wall or simple stories in a PM tool. I save seen them in the hundreds, even over a thousand. I’ve been a PO myself and when my backlog of ideas was more than 20 or so deep I started to get bogged down in ordering. To order a list you have to look at the entire list! I started to realise that the stuff down the bottom was likely never going to be done or become important.
I also knew that if I was wrong and the ideas did emerge as important then they would do exactly that – emerge. I wasn’t going to suddenly look down the bottom of the list and say “you know what, we should do that first”. Well, I might have done, perhaps. But my point is that if my list is massive I will never look down the bottom of it, so there may be a greater chance of me *not* doing what is most important *because* I have a product backlog.
Nothing wrong with a long backlog in my opinion. I’d rather have a Product backlog that has plenty of stories ready – knowing it will change all the time – than a backlog which only has a one sprints worth of work. The Product Owner must not need the information that badly if she prioritized in the manner she did and she owns it. My question would be why is there a need for documentation if a conversation would suffice?
It’s not working software INSTEAD of comprehensive documentation. It’s just that working software is valued more. Perhaps there’s a chance to find a middle ground to generate the documentation that’s necessary going forward? There’s value in documentation for sure.
Back to the value question: Would they really prefer not-working software with comprehensive documentation?