Keeping track of the backlog in a Scrum project is a challenge. It quickly grows to hundreds of items that are in various state of readiness for inclusion in a sprint. In my current project, we’ve setup a Kanban board to help managing the backlog and make our backlog grooming sessions efficient.
I think that in many ways the product backlog and the product owner role are Scrum’s weak spot. Scrum brings order to the development process and sets clear demand on the specifications input into the development process. That helps to make visible what we developers have known all the time: It isn’t our fault that projects screw up, because we can’t do a good job on bad requirements. So with Scrum having helped to make the requirement problem visible to everyone it’s time to address the requirements handling.
In my current project, there are a number of distinctive steps that a product backlog item goes through.
- A new request from someone is noted as a product backlog item.
- The PO decides to trash it right away, or to go forward with more detailed analysis.
- The PO (or a BA helping the PO) makes an analysis.
- The product backlog items is presented to the developers in a backlog grooming meeting.
- The developers have questions and send the item back for further detailing.
- The developers approve the item and make an estimate of the entire product backlog item.
- Only items approved by the developers are eligible for inclusion in a sprint at the sprint planning meeting.
To keep track of this process we use a Kanban board.
Business software has automated many routine tasks. Is there anyone still doing accounting manually? The automation is also applied to software development itself, removing routine tasks and leaving the hard tasks to solve manually.
15 years ago I was thinking of what a future career as a programmer would look like. I didn’t know much about professional development, but I was sure of one thing: Administrative business applications was not an option. I wanted to do something new, creative – not spend my days adding another field to another form (including adding it in CRUD code, CRUD Stored Procedures and the database schema).
Now I’m here, working with administrative business applications and enjoying it. It’s not at all what I thought of it back then. It’s far more interesting and challenging.
The tools have become so much better. 10 years ago, a single added field to a form could require changes to 10 different places in the code – all of it plumbing code. With the frameworks available today it’s often possible to handle it with just two changes – one to the GUI and one to the database schema. The rest can be handled automatically.
With routine tasks automated, the focus moves to two different areas: The hard problems and the customer requirements. This makes programming more qualified than ever. It requires deeper expertise within both technology and business understanding.
With authority follows accountability. The other way around is also true. Anyone who’s held accountable has to have authority. Unfortunately it is far too common that developers are held accountable for a project, even though they don’t have any real authority. They typically are responsible for the delivery, but the authority stays on management level and that’s where the accountability belongs.
A bad manager will take all the credits for the success, while any failures are blamed on the developers. A good manager of course does it the other way around, but let’s ignore that for now. This post is about bad managers that do not accept the accountability that comes with authority.
There are two different cases where the developers are held accountable without having authority.
- The developers should really be accountable and have the corresponding authority, but management won’t delegate the authority.
- Management has the authority and they should, but they refuse to accept the accountability that comes with authority.
Setting priorities is hard. When a customer is asked to number 10 items with priority 1-10 it often ends up with one 10, two 5s and seven number 1. That usually means that there is one item that isn’t worth doing at all (the number 10), two items that are nice-to-have (the number 5s) and seven items that are really needed.
When coding, one thing should be done at a time. Trying to get everything started at once and multitasking is just inefficient. When given items that are “prioritized” like the above example the order in which to do things has to be defined.
In one project I worked in the managers actually made a priority like this. To refine it they then set letters to distinguish between the number one priorities. I even think they got as far as introducing another number, to distinguish between the different items with priority 1a, giving priority 1a1 and priority 1a2…
That’s ridiculous. When setting priorities I have a simple rule to the top priority:
There can be only one
Some time ago a colleague of mine, Monica Hervén, asked me for some advice. I was a bit surprised, because she’s a lot more experienced than I am and she’s someone who I have a lot to learn from. The issue she wanted to discuss was how to identify the requirements in a scrum project she’s involved in.
In the first post in this series I described how the requirements phase is generally treated in descriptions of scrum.
A scrum project starts with an almighty, all knowing product owner that has the entire list requirements prepared in a prioritized product backlog.
The problem Monica faced was that there was no clearly defined, prioritized product backlog produced by the appointed product owner. I don’t think that I had very much new to tell Monica that she didn’t already know, but we could share some experience of the challenges of getting a good product backlog produced.
The product backlog is the initiator for all work done in a scrum project. It’s the responsibility of the product owner to produce it. That makes the product owner role extremely demanding. It is impossible for a product owner to just conjure up a product backlog. Forming the backlog requires hard, structured work to ensure that all relevant user stories are identified.