This post is about the importance of building a proper backlog with accurate, specific, and deliverable stories without any missing functionality. First of all, we have to accept the fact that it’s nearly impossible to discover and predefine all functionality and requirements up-front. That’s the fact of life. However there is a certain degree of quality that needs to go into the backlog. The dangers of a poor backlog are numerous and it touches everyone - developers, clients and other stake holders and its effects are reflected in the final product.
In general it’s relatively easy to spot a poor backlog, it usually has these features:
- Very broadly defined stories without a clear scope.
- Stories that don’t have enough technical detail to know what actually has to be done.
- Stories with overlapping functionality (or worse - duplicate stories).
- Missing stories (these are obviously more difficult to see).
- Generally sloppy story names and descriptions, including incorrect grammar and inconsistent styling.
As a developer if your backlog stories aren’t defined well enough - and if you are at all invested in the project and feel some degree of accountability - you will try to correct those shortcomings during the sprint. But at what price?
Overtime.
You may of course ignore your commitments and simply refuse to do overtime. In that case you will not deliver what you’ve promised, making your team look bad.
Sometimes you might still manage to deliver all the functionality, but because you were in such a rush, your code is a bunch of spaghetti.
None of these outcomes are what anybody wants. And all this evil comes from one mistake - not giving enough time and attention to building a good backlog.
So what is a good backlog?
A good backlog is the one where all stories are clear, all important functionality is defined, stories do not overlap and are independent. A good story (from my personal experience) has these elements:
- Story name consisting of only 2-5 words
- Story description from client’s perspective
- List of technical tasks that will need to be done to complete the story
- A dependency graph showing which stories are dependent on which (ideally there shouldn’t be any dependencies, but that’s not always possible)
It might take some time to put all that info together, but it’s well worth the investment, and will save you lots of time and headache later on.
TL;DR
A good backlog with good story descriptions plays a critical role in ensuring delivery of high quality software on time. For this reason the activity of backlog grooming must be given utmost importance and must be done with lots of attention to detail and never in haste.