Good Product Owner Wrapup

Dear Junior

I would like to wrap up our discussion about the good product owner and the characteristics thereof. Of course there are many important attributes, and there are even more ways to select words for them. However, I think a lot of them are caught by the two-by-two containing "engaged, involved, decisive, and empowered".

                  personal   organisational

social:       engaged    involved

formal:     decisive    empowered

It does not tell everything about a good product owner. It is just a model, meant to capture some important points in a concise way. So, let's just have a walk around this picture.

Starting with engaged we have a product owner that cares, who thinks the product and the system is important. This product owner has an inner drive to do things for the benefit of the product. So, it is a personal attribute. Also it is not so much about mandate and formalities, it is more about interacting with people, so "engaged" is set in a social setting.

Moving over to right we stay in the social setting, but transfer to the organisational attribute of being involved (from Latin "in the turning"; today we would probably say:"in the loop"). We are still talking about "interacting with people", but now it is not the person's inner drive. Instead it is the organisation "letting" the PO being involved. Rephrased, the organisation thinks that being product owner is the most important thing on this persons job description - there is nowhere else this person rather should be.

Moving down we stay on organisational attributes, but switch to talk about formalities. Being empowered is all about having the organisational mandate to take decisions that will stand. Of course the product owner can change her mind, and re-decide something else later. However, that is the decision of the product owner herself - not something the rest of the organisation can force upon her. The PO is a little bit like the "local CEO" of the product.

Moving to the left we stay on formalities, but move back to personal attributes. Being decisive is to have the personal drive to actually make decisions when they are needed. Of cause even a decisive person can change her mind, but the good product owner will take decisions with respect to the team, not throwing them "of balance" by completely changing direction. Still it is being decisive in the moment needed that keeps progress going.

Moving up we stay on personal attributes, but cross the border of formalities back to social settings and we end up at engaged where we started.

Now, this model is nothing but a model, and thus it is limited in its power and limited in its reach. In other words: it misses a lot of important points. It is also a product of annotating specific words specific meanings, that are by no mean ubiquitous.

Other words

Steven Hale pointed out that the distinction between "engaged" and "involved" is unclear (to say the least). He has suggested "interested" and "active" as a more distinct pair for the social attributes. This also makes the acronym IDEA possible  - which is neat. However, in defense of "engaged/involved" he also notes that there was a girl with whom he got involved, later engaged, and now they are married.

Important things missed

There are also important things this model leaves out. One of the things Joakim Holm pointed out is that fails to mention the "burning vision" the product owner should uphold. I could not agree more - that is one of the most of important things a product owner should establish, nurture, and communicate (I am keen to say "radiate"). And that dimension is not caught in this discussion on "characteristics".

In the end - this two-by-two is just a model. Being a such some important things fall outside, for the simplicity of expressing many important things concisely. To me, this model capture a lot of important attributes.

The way to judge a model is not whether it is "true, or not". It is whether it is useful in important circumstances. Personally  have used this model a lot of times when trying to figure out what is wrong in situations that does not work well. It has also deepened my understanding of agile and how it relies on humans, as individuals and their interactions, rather than setting and trusting formal structures.

I hope it will come useful to you.

Yours

   Dan


ps So, who will become a good product owner? Well, for example, I have met some really good project managers that I think would become excellent product owners.

Empowered Product Owner

Dear Junior

Let us say that you have a product owner personally engaged, organisationally involved, and who is decisive enough to take decisions. For having a good product owner you only lack the fourth characteristics; you want the product owner to be empowered.

Engaged Involved

Decisive Empowered

Of course it does not help much having a product owner taking decisions if she does not have the authority to do so. The problem is that any decision the team has started working from can suddenly be revoked. 

Sorry folks, I just talked to the Guy-Who-Decides-Stuff and you remember that delimitation we settled for yesterday …. well, to make a long story short, he thinks it is an over-simplification, so we cannot do that. I am really sorry if it messes up things for you …

Agile methods in general are built do handle change. But you want that change to come controlled — not on things in-sprint after you have spent considerable time and effort working on it. If the team gets contra-orders repeatedly during a sprint they start mistrusting the decisions and guess if they lose tempo!

This is really what I do not like about "Proxy Product Owner". Such a one can be engaged, involved, and decisive. However, they are not empowered - the "Real PO" is somewhere else and any decision might be overruled. The unfortunately result is often that the Proxy PO gets indecisive.

Proxy PO: Sound good, just let me check with Guy-Who-Decides-Stuff. I will know for sure by tomorrow.

Team: So, what do we do until tomorrow? 

Point here is that the team loses focus and tempo.

To make things worse, the etymology of the word "proxy" unveils that "proxy without authority" is a misuse. The word is closely related to "procurator" which was the province manager in the Roman empire and who held administrative powers as agent of the emperor. No talking here about "have to check with the Emperor in Rome first".

So, what to do about it? 

I told you about the example of the non-involved Head of Marketing. In that case, someone else did the day-to-day job. Taking care of the backlog etc was done by an assisting controller from economy department. And he had to constantly run around the building to chase down stakeholders to validate any decision he made. The poor bastard did not even have the title "Proxy PO".

The solution I advice is to empower the Proxy to become the Real Product Owner, and the Head of Marketing in this example will become one important stakeholder. 

In some organisations this sounds strange: "Can you give authority to someone who is not the boss?" I would argue you can.

I think of the relationship between the product owner and the stakeholders a little bit like the relation between the CEO and the Board. The Board is not the "boss" of the CEO. All decisions the CEO makes, she makes based on her mandate. If the CEO makes consistently bad decisions, she will be replaced - but until that point of time she has her mandate. Of course the good CEO will carefully listen to what the Board thinks is important. But, the decisions will be her own.

In the same way, the stakeholders are not the boss of the product owner. All decisions the PO makes, she makes based on her mandate. If the PO makes consistently bad decisions, she will be replaced. Of course the good PO listens carefully to what the stakeholders think is important, and try to balance those interests. But, the decision will be her own.

In traditional organisations there is a glory around the word "owner" that tend to push the title "up the ladder". If it is a really important system, then it might make sense to have the Head of Marketing to be product owner. But then the system must also be important enough for that person to spend considerable time on its development. Otherwise, delegate both the task and the authority to someone who has the time.

This is actually nothing but an instance of the good advice on organisational structure: Strive for aligning task, competence, and mandate.

Sounds pretty obvious, but it is interesting to see how often these are not well-aligned in many organisations.

Being empowered is a characteristics in an organisational context, in the same way  as "involved" is "allowed by the organisation to spend time with the team". However, it is not so much about the informal situations that "involved" is mostly about, it is more about when there are time to make decisions. In that respect it is more related to being decisive.

Engaged Involved

Decisive Empowered

If you are in an organisation that manage to hand you an empowered product owner, you have a good chance to keep things rolling.

Yours

  Dan

Decisive Product Owner

Dear Junior

In the list of characteristics of a good product owner, we have this far discussing those in informal situations - being engaged and involved. However, product ownership is also a lot about making decisions, and then I like the product owner to be decisive.

Engaged Involved

Decisive Empowered

System development is a lot about making decisions. Even when we write code (and perhaps especially then) we make hundreds and thousands of micro-decisions. Some of them have mainly technical implications (make this design one class or two), but some of them form enterprise logic (what fields should I use when computing this if-conditional).

Sometimes these decisions grow a little bit larger, and we want to ask someone about what we should do. For example we might be writing a batch-file reader and wonder how we should handle if someone sends in the same file twice. Perhaps we consider saving some kind of file ID and a content hash to detect that situation. This might take a day or so to implement so most probably we will bring that up during the daily standup. 

That standup is when the product owner can step in and make a huge difference. Of course the PO needs to be there (involved) and needs to care (engaged), but if she is she might make a huge difference by saying: 

"Hold that thought. To me that seems like a separate story (Avoid duplicate file read). It is good enough if you implement this without that feature. if same file is sent twice, and we read it twice - then so be it. I make it new story and bring it up with the stakeholders."

Viola, within one minute the product owner have saved the team one day of coding, just by being decisive. 

Product owner need also be able to take decisions at point blanc, even when there might not be enough information. 

Team member: "I wonder, what shall we do about social security numbers for people with protected identity"

Product owner: "I do not know whether we have a case for supporting protected SSNs - need to check that up. Ignore that feature for now, if necessary I will add that as a new feature later."

This is just a few minute conversation, yet it saves the team hours of work by not loosing tempo.

Being decisive rules out product owners that "just want to investigate a little bit further before saying anything definitive" - such behaviour leaves the team floundering on what to do, whether they can proceed on the assumption or if they should wait.

Being decisive is a characteristic in a personal context, as is engaged. However it is more about making decisions rather than informal situations - so in that respect it is more related to being empowered.

Engaged Involved

Decisive Empowered

Nevertheless, having a decisive product owner makes things so much easier to keep things rolling.

Yours

   Dan

Involved Product Owner

Dear Junior

Let us continue the discussion about four characteristics of a good product owner. Having an engaged product owner is very well, but it does not really help much if she is not involved.

Engaged   Involved

Decisive   Empowered

Being involved is basically spending time with the team. I want the product owner to show up at daily stand-ups, and to be available for questions and discussions. Without being involved, the engagement does not lead anywhere - like "that is a really interesting and important point; we really need to discuss this, but unfortunately I am extremely short of time  - can we set up a meeting next week?". Few things stops up development more that not being able to put forward those important questions and have those discussions.

Being an involved product owner is much about discussions and other informal situations - much like being engaged also is. However, where "engaged" is an attribute of the person, I would say that "involved" is an attribute of the organisation: does the (rest of the) organisation let the product owner to be involved or does it expect her to be elsewhere?

Having the product owner being involved rules out product owners that have lots of other important stuff to do, and being product owner will have to take whatever time that "is left" (obviously seldom more that extremely little). Product ownership is nothing that can be handled "on the side, with left hand".

One striking example is the Head of Marketing, who was the product owner of a web sales system. However, that person had so much to do with campaigns and strategy planning he did not even have time to come to the bi-weekly demos. 

It is not uncommon to hear this kind of situation "solved" by a Proxy Product Owner.  The proxy will fulfill the "involved" part while the Real Product Owner is elsewhere doing more important stuff. I do not think this is a good solution.

The Proxy Product Owner does give the team someone to talk to and discuss with on a daily basis, the problem is that that person seldom hold authority to take decisions - and if they do those decisions often need to be ratified by the Real Product Owner. In the two-times-two-matrix, it is rather a problem about being empowered - so let me return to the Proxy Product Owner in a later letter.

Engaged   Involved

Decisive   Empowered

Being involved is an attribute that applies to informal situations, like being engaged. In contrast to "engaged" it is however not so much about the person per se, but rather about the surrounding organisation. In that respect "invloved" is more akin to "empowered", with the distinction that the latter is more about formal decisions.

Still, having the product owner involved in the daily work is crucial for success.

Yours

   Dan

Engaged Product Owner

Dear Junior

One of the things I appreciate with people I work with are that they are engaged, and a good product owner is no exception to this. Thus, in the list of four characteristics of a good product owner, I would like to start with that one.

Engaged   Involved

Decisive   Empowered

With "engaged" I basically mean that the product owner should care about the product that we are working on together. This manifests itself as the product owner wanting to participate. 

For example, there might be a problem with some story that is under development - border cases might be unclear or we have unveiled an alternative flows that we did not foresee. In that case, the product owner should consider it important to discuss those to help the development move forward without stopping. Or, if there is a business concept a developer do not understand, the product owner should want to explain it.

Further than that, the product owner is not just reactive. The engagement is also proactive. As an example, there might be a story on the backlog that the development team has deemed too big or unclear to start developing. The product owner should then consider that important enough to work with stakeholders and developers to re-phrase that story in a way that makes it more feasible for development, e g by delimiting it or splitting it.

Being engaged rules out product owners that became product owner "because someone had to be" or - even worse - where ordered to take that position, perhaps against their wish. Such a person will have no particular interest in the system, how it is used, or how it should evolve.

So being engaged is mostly about informal situations - like being involved - not about formal decisions. And it is also an attribute in a personal context - like being decisive - not about what the surrounding organisation lets you.

Having an engaged product owner is crucial for sustained success in development.  

Yours

   Dan

Four Characteristics of a Good Product Owner

Dear Junior


A good product owner is hard to find — but it is well worth the effort. Once a development team start becoming agile it does not take long before the quality of the product-ownership becomes one of the most significant factors for the  productivity of the team. A good product owner works with the rest of the team to gain and uphold a high velocity. A bad product owner can slow the team down to close to a grinding halt.

I have seen several organisations that have attempted to establish a product owner role, where some attempts have succeeded and others have failed miserably. I have tried to find some way to characterise the product owners of these organisations where I have seen success. Finally I have boiled it down to four characteristics that are to some degree linked to each other.

The product owner I have come to appreciate can be summed up by being engaged, involved, decisive, and empowered.

Engaged   Involved

Decisive    Empowered

Of course, each word here have a multitude of interpretations so some explanation is needed to clarify what  I mean. I will elaborate each of them in subsequent letters, but right now I just want to try to convey the larger picture to you.

Context - Person and Organisation


One thing I find interesting with this list of four characteristics is that it contains attributes of the person being product owner as well as the organisation surrounding that person. On one hand side, being engaged and decisive are personal attributes — they come from the "inside".

Engaged   Involved

Decisive    Empowered

On the other hand being involved and empowered are attributes given by the surrounding organisation, it can let you be involved or being empowered, or it can stop you from doing so — they come from the organisation environment.

Engaged   Involved

Decisive    Empowered

So, the verticals in the matrix is about the context — personal or organisational.

Situation - Informal or Formal


In a similar manner the attributes describe how the product owner acts in different kinds of situations.  Being engaged and involved are about informal situations — day to day discussions, coming to daily stand-ups , etc. 

Engaged   Involved

Decisive    Empowered

On the other hand we have decisive and empowered. These are attributes that talk about formal situations — when there is a decision to make. The decisions are small as well as large. A small decision can be to scope a story during sprint, a large decision to say: "let's release". Disregarding small or large, those decisions are important.

Engaged   Involved

Decisive    Empowered

So, the horizontals in the matrix is about situation — informal or formal.

I definitely want to dive into each of these characteristics, but that will wait for another day.

To sum up this observation: I think this cross-section of personal-vs-organisational context and informal-vs-formal situations neatly catches most of the really important parts of what a good product owner is like, and what behaviour it leads to.

Yours

  Dan

Complexity Drives Effort

Dear Junior

There has been a recent discussion on story point estimation (or sizing) that is so common in Scrum. Especially the discussion has been about how sizes should relate to complexity  and to effort needed to complete story. In a blog post Mike Cohn made a good example between effort and complexity by comparing "licking a thousand stamps" on one side, and "performing a simple brain surgery" on the other side. These where assumed to take approximately the same effort, but had drastically different complexity. Point was that they should have same amount of story points.

It is Effort that Makes a Difference

I think there is a lot of merit to the point Mike makes that it is amount of effort that is the usable parameter - we need it to make rough cost estimates and to predict what  functionality can plausibly be released when. Complexity is not usable in the same way.

However, even if "effort" is what we primary care about, to me complexity plays a very central role - more than I have seen mentioned in the discussion. To clarify I would like to dive into the thousand-stamps-example.

Story is Effect, not Task

To start with, the team should not get a story saying: "lick a thousand stamps"; because that prescribes a specific solution. A good story should only point out the desirable effect, and leave to the team to pick a good solution. I guess the story could instead have read: "ensure a thousand stamps get licked", or something along that line. The difference is subtle but important. In the first case, the team is given a task to perform. In the second case, the team is given a problem to be solved. 

Bulk Driving Effort

If you are to lick ten or a hundred stamps, you will certainly just do it. If you are to lick a thousand you will get mighty bored and tired - with ten seconds per stamp that amounts to three hours of work. However, it is still manageble, so you just get onto it. So here the effort will be driven by the bulk of the job - more stamps, more effort.

However, if you are to lick ten thousand stamps, or a million, then you are facing another magnitude of effort. To lick a million stamps would take 10 000 000 seconds, which is 70 weeks of full-time work - the better part of two years. Facing that task I would probably start building a stamp-licking machine.

Interesting enough this changes the game. The effort of building such a machine is independent of the amount of stamps to be licked. It is roughly as hard to build such a machine whether it will lick thousand or ten million stamps. So, bulk does no longer drive the effort.

Complexity Driving Effort

So, how hard is it to build a stamp-licking machine. Well, the actions involved is pretty straight forward, there are only one set of maneuvers, and no decisions to make - so, not-too-hard is a fair guess. 

And here comes the other half of the interesting change of the game. The effort is decided by how hard it is to build such a machine - i e the complexity of the task. So, bulk does not drive effort any longer, instead it is the complexity of the task that drives the effort.

Software Development Teams do not do Bulk

Going back to software domain, the equivalent of licking lots of stamps (10 seconds each) is probably to send a pre-formatted mail to a long list of email addresses found in an excel sheet ("new mail", CnP mail content from template, CnP email from next line in sheet, "send").

A team of developers given the story "send mail to top thousand customers" would certainly not open Outlook and start at top of list. Instead they would write some script that generates a mail to mailer daemon given the to-addr - effort 15 min. Then they would write another script that loops over a text-file with email addresses and sends same mail to all of them using first script - another 15 min. Last, they would export the mail addresses from the excel sheet to a file, feed it to the looping script, and off we go - another 10 min. OK, let us allow for extensive testing and coffee break but we are still around two hours.

Complexity Drives Effort

The important point here is not whether the script-solution would be faster or not. The important point is that the effort needed is not determined by the size of the batch. The effort needed is determined by how hard the problem is to solve - how much time must be spent discussing design, how tricky it is to get right in coding, how much testing is needed to feel confidence in the solution. In other words, its complexity.

The effort which we need to put in to solve a problem in software development is very much a function of the complexity of the problem. The complexity can be essential to the problem, i e if we are working in a knowledge-intensive domain. This is of course the call for Domain-Driven Design. The complexity can also be accidental, e g if we have an over-complex architecture or a codebase in bad shape. This is of course the call for software craftsmanship.

Disregarding the reason, overcoming said complexity will be what decides whether we need to spend a lot of effort or not. 

Sizing, or estimating, in story points should definitely reflect the amount of effort we think we need to put in. However, in most cases it is the underlying complexity - essential or accidental - that drives that effort.

Yours

   Dan

Ps On of the reasons why complexity of problem is so central is that software development to a large degree is a knowledge journey.

pps It is easy to be fooled into discussing what "story points really are", but from a pragmatic view that is uninteresting, unless it makes a difference. What matters is "what story points are useful for", i e the point of story points.

Release Planning Spreadsheet

Dear Junior

From time to time I have had to start setting up a backlog, start tracking velocity, and create a release plan in parallel. This situation is a little bit of a nuisance as I prefer the "scientific approach" of letting data speak. In this case that means observing the velocity of the team for a few sprints, have a look at the backlog, and then base the release plan on that data. Inspect and adapt. Inspect velocity, inspect backlog estimates, adapt release plan.

The problem is that this is a little bit hard to do when you are asked to present a release plan before you have no, or just a few, observed velocities to deduce from. Strangely enough executives seem to be accustomed to project managers with precognitive skills, and I unfortunately lack those. So, those before me have set the expectations and "not enough data yet" seem to be considered somewhat a "weak excuse". I do not blame the executives, I blame the project managers that have set "speculative guesstimates" as the standard - easy to make, hard to fulfil.

Luckily it is often possible to stall the release-plan for some time, which gives some lee-room to gather a few velocity data, and get the backlog in decent shape.

When you have at least eight sprint velocity observations, Mike Cohn has a neat short-hand trick for releases at least four sprints into the future; I have mentioned this trick in an earlier letter. However, when having less data, I have used the analysis of the mentioned method to squeeze the maximum information out of just a few sprints of observations.

The problem is that you want to give an interval you feel confident with (e g 95% confidence) and it takes some time to gather enough data for creating a decent interval.

In short:

• velocity from one sprint is useless, it gives you an idea about average, but nothing on the variation
• velocity from two sprints starts giving you a decent average, but with only two data-points it is hard to judge variation and giving an interval
• velocity from three sprints starts giving you a fair idea on variation, and you can give an interval

Of course, the calculations can be done through standard statistical computations. However, doing that number exercise is a little bit unnerving when you have lots of other things to think of.

Therefore I have put together a handy cheat-sheet, which I by the way did share with a few people who attended my session on Why Release Planning Works at the just-passed Scrum Gathering in München (Munich).

In short, you fill in how many sprints until release, and then observed velocities.

After each observation, the sheet tells you the interval of 95% confidence of how much you will cover in the remaining sprints, and how much the total sum of work will accumulate to.

It also plots out a nice graph if you care to share it with the stakeholders.

A word of advice and warning when presenting the release plan to stakeholders: I prefer to talk about what stories seem to be in the release (before the 95% interval), which are in doubt (those in the interval), and which will not make it (those beyond the interval). If you present the numbers as such (or this graph), they might start taking those numbers a little bit too serious. You definitely stand the risk that upper management might start viewing it as a productivity measure, which will destroy its usability within a few sprints.

Composing a good release is also an art in itself, and much more that just picking "most valuable". A good release should contain what Kano-analysis describes as the mandatory features, and a few linear - but also at least one "exciter". If not, people might be well satisfied with it, but not raving about it. So, the spreadsheet gives a hint of what "budget" you have for the release.

Anyway: hope you will find the spreadsheet interesting, and at some point useful.

Yours

Dan

Heapsort, the Binary Mafia, and Product Backlog Priorities

Dear Junior

I recently picked up my university book on algorithms and by accident came across the section on heap-sort and its data structures. When reading it, I was struck by a strong association to product backlogs and how product owners keep them sorted, often spending a substantial time on that task.

A common advice to product owners is to give each user story a priority by attributing it an “importance number”. High importance number means important story, so if you want to send a story to the top, you can always change its number to being higher then the currently most important. This is a neat trick eliminating the common problem when things are given priority numbers (where “priority one” is most important) – because what do you do when something even more important arrives? Give it “prio zero”?

In the same breath, product owners are usually advised that all stories should have unique importance numbers, thus distinguishing them. For those stories that to be developed in near future (what I call the “Backlog Shortlist”), it is important to sort out their relative priorities, and I agree that assigning unique numbers to those stories is a feasible way to do it.

However, for the rest of the backlog, setting unique numbers is unnecessary work. Following the advice forces us to determine the exact order of even the bottom ten, most unimportant, stories – and to do this at an early stage. Guess what – those priorities might, and will, change many times before those stories are ripe for development. Chances are high that those stories will not even be developed, at least not in their current shape. So basically we have wasted precious product-owner time on establishing details that was not needed yet – what I call “premature exactness”.

Going back to the algorithms and data structures, this reminds me on how a list is sorted using insert-sort, where a new item “scans” through the list to find its place in the sorted list. Doing this with one element at a time with all the elements you want to sort gives you a sorted list with the most important element at the beginning. If you extract the most important element one at a time from that list you obviously get them in priority order. Also, if you let new elements enter the list during the process, you have a what computer scientists call a “priority queue”. The connection to the backlog should be obvious.

However, it turns out that insert-sort is a pretty bad way of implementing a priority queue. This is because inserting a new element requires you to scan half the list on average – in other words, inserting a new element is linear to number of elements in the list, or O(n) using computer science terminology. So, the complete work for processing n original items through the priority processing will be O(n*n).

Heapsort on the other hand uses another data structure called the “heap”. This heap is a binary tree with some extra restrictions on how nodes can sit relative to each other – not to be confused with garbage collected memory area used in runtime environments such as Java or LISP.

What makes the binary tree into a heap is an extra property – each node has a value that is larger than its immediate children’s. Thus, the largest value will be at the top. However, in the heap the nodes do not care about whether the right or the left child is larger; nor does it care about the values in the nodes two steps down. And it is exactly this ignorance of irrelevant details that happens to make the heap an excellent structure for implementing a priority queue.

I think of a heap as a Mafia organisation with branches. In each cell (tree node), the toughest guy or gal is the cell boss with two subordinates - each being the boss of one sub-branch each. The other way around, the tough boss is part of another cell (the tree node above) where the boss of that cell is yet tougher. And of cause, at the top is the head boss (root node) that is the toughest of them all.

So, as there are two sub-bosses that are directly under the head boss – are those two the second and third toughest in the org? Well, one of them is the second toughest, no doubt – but the other one might not be the third toughest. He or she might just be lucky enough that the third toughest is not in his or her part of the org. The third toughest might be one of the underdogs to the other sub-boss. This is the same way as it is not necessary the second best team that plays the final in a cup. The winner of the final should be the best, but the second best team could have lost against the best in some early round.

Back to the Ma; it is easy to know who’s the toughest; it’s the boss right at the root of the heap. But what happens when the head boss get shot ("extracted from the heap")? Well, the two sub-bosses will challenge each other, and the toughest will step up to take the empty place. Now, there is a vacancy for the promoted sub-boss's position. So, the toughest of the two in that cell will step up to fill that vacancy, leaving a vacancy another step down in the hierarchy – rattling down through one “leg” in the tree. At each level there will be a challenge between the peers on who is to be the new boss, and the number of challenges in total will be the height of the tree, which is roughly the logarithm of the size of the org. So, appointing a new head boss when the old gets shot is a O(lg n) operation.

So, what happens when a newbie enters the org? Well, the newbie will enter as a leaf node in one of the cells, reporting to some lowest level local cell boss. Now it well be that the newbie is tougher than the local cell boss, it which case the latter will be challenged, and they will switch places, the newbie being the new local cell boss. Of course, the newbie might be tougher then the next level boss as well, whereupon there will be a new challenge and another switch. At worst, the newbie will be tougher then everybody in the org, and will challenge his or her way all the way to the top becoming the new head boss. This will take as many challenges as the number of levels in the org – i e again, the tree height. So, accepting a new member is a O(lg n) operation.

If inserting a new element is O(lg n) and extracting highest priority element is O(lg n), then processing all elements of a list takes O(n lg n). As product backlogs often can be some thirty to hundred elements (if not more), the difference between n*n and n*lg n is substantial – especially if we talk about using precious product owner time. So, heap-sort is a much better role-model than insert-sort when grooming our product backlog.

How come the heap performed so well? Its efficiency stems from not keeping the entire queue perfectly sorted. Instead it focus on the most important thing – to keep the “toughest” element at the top, and keeping the rest of the queue roughly sorted where “tough” elements tend to hang around at the top, and ”lesser tough” somewhere lower down. Thus it avoids premature exactness, e g decisions that are not needed yet. I also think about is as some kind of "fuzzy late evaluation" - if you get what I mean.

Applying this back to our product backlog, we might go so far as to structure our backlog as a heap. That would be cool but I have never done it, but I am definitely looking for the opportunity. Taking some of the wisdom back, we have learned that it suffices to have the lower part of the backlog “roughly sorted”. One way of applying that would be to relax the requirement on unique importance of each story. We should still require unique numbers for the shortlist, but for the rest it suffices that there are strata of stories that are roughly as important and which might share the same importance number.

Yours

Dan