There was a change made to the Scrum Guide a few years ago around the language used to describe what the “most important” thing is. Previously it was okay to talk about “prioritising the backlog” or “what order we should tackle the work” as these terms were synonymous.
But not any longer it seems. Now the terms “priority” and “order” mean different things, i.e. the priority of the product backlog does not necessarily define what order we tackle the work. If this sounds odd to you then you are not alone. While in theory the distinction sounds useful, in practice I’ve only found it to create more friction.
Pointless Pedantry?
The reason for introducing the subtle distinction was outlined in “Ordered Not Prioritized” by James Coplien. Anyone who has worked in a team where there has been tension over how to order the backlog so that work is done efficiently, which might not be the same order that the business would like, will know where Jim is coming from.
Whilst there is nothing intrinsically hard to change about software, as it is after all essentially non-physical, there are still constraints, such as complexity, which dictate how easy it is to achieve. The non-technical folk also may not understand that there are still limitations in the tools and materials that we work with. For example one tool may make it easier to get something simple functionally complete quicker, but its inability to scale adequately may make it the wrong choice for anything other than a prototype.
Balancing the business and technical priorities is tricky. They want features quicker, but we want to keep the quality bar high to ensure the product is able to support continued change. This is not an all-or-nothing proposition. Aside from the initial stages of development were we are mostly erecting the scaffolding that will support continuous delivery, the bulk of the work can be a mixture of the two.
I’ve been in the situation before a few times where there have been attempts to try and resolve the business and technical priorities by splitting up the backlog. This just doesn’t work, no matter how you slice-and-dice it there can only be one top priority. Making the team decide whether they should pick something off the business or technical backlog is not honouring the “negotiation” aspect that the agile manifesto promotes.
Hence, there almost certainly should be one, and only one backlog to ensure that everyone on both sides of the fence (business and technical) understand what we’re building in the shorter term and what’s further down the line (subject to renegotiation at any point). Having a single stream of work makes it really easy to see at a glance what the current plan is.
It’s All Just Work
Whilst Scrum might be straining the language in terms of priority at least it keeps the units of work simple – items. Over the years there has been a proliferation of ways to describe ever larger chunks of stuff to do from tasks, to stories, to epics and eventually to themes.
I’ve overheard conversations where people get hung up on the relative sizes of each of these bundles in the hope that they will be able to estimate the entire project delivery by just summing up the various factors. This naturally leads to a proliferation of charts showing the burning up (or down) of each of these units to help maintain the illusion that we are in control of the project and it’s progress and that we’ll meet whatever arbitrary deadline has been decided.
Breaking work down into small, manageable chunks is what matters. Each chunk of work should deliver some value, and by keeping them small we give ourselves room to manoeuvre and change direction (within limits) to meet the ever changing world around us. Just as when talking about the software architecture we tend to talk at different levels of abstraction, and so we can do the same with our features. This allows us to remain focused on, say, the bigger picture and not get unnecessarily bogged down in details which are superfluous at that level of granularity.
Many of the techniques around planning and estimation are largely exercises in getting you to break the problem down and identify risks to delivery. As long as the team is able to talk about the work and know at what “level” the current discussion is taking place, they should avoid getting distracted by arguments about whether any given feature is a task, story, epic, etc.
Back to Basics
When we cut away all the new terminology that has arisen over the last couple of decades we get back to a very simple development process. In essence we have a list of things that the business would like us to do, along with some other stuff that the implementing team also need to do, in order to ensure all this work happens efficiently.
That “to-do” list will contain work of varying size and complexity and both the business and technical sides will endeavour to break it down into small enough chunks that they can interleave them to ensure their respective needs are continually being met. The team will also periodically reflect on their working practice to help them discover even better ways of working.
And that’s pretty much it. Ultimately what we’re trying to achieve is very simple and yet the language often gets in the way and causes us to worry more about the process we’re following instead of what actually matters – creating working software.
No comments:
Post a Comment