Agile Projects should have Effect Targets

Dear Junior

Measuring projects and setting targets for them is a tricky business. And, it does not get easier when agile projects enter the scene. This is not really because agile projects are strange per se, but because they are different from non-agile projects.

Setting targets and measuring projects is also an important business. I have seen several agile initiatives fail. Most of them have failed because they did not succeed in setting goals for projects, and monitor their progress. And if you cannot do that, you quickly lose the confidence and support from upper management. Agile initiative terminated, or left to dwindle away. End of story.

However, it need not to be so. Agile projects can have measurable targets, and they can be monitored - you just have to do it right.

There are some bad news and some good news.

The Well-Established Chaos Rod for Measuring Success

The bad news is that agile projects cannot be measured using the de-facto established standard rod for project success.

The standard rod for measuring projects is "on-time and on-budget, with all features and functions as initially specified", as used by e g Standish Group in their much-to-cited Chaos Reports. Let us call this the "Chaos rod". Most organisations use some version of the Chaos rod for measuring their projects.

As we have discussed earlier it is pretty obvious that "all features implemented" is not a good way to measure "project success" - not for any project. Nevertheless, this is the standard rod.

Damned if you do, damned if you don't

Of course agile projects will fail if measured using the Chaos rod. The reason is simple - agile projects does not manage to keep their hands away from fiddling with the original specification. Agile projects remove stuff, change stuff, add stuff - agile projects are in a constant state of scope-creep.

This is no coincidence - it is how agile projects are designed.

Think of it this way: If we learn something during the run of the project - shall we let that insight effect the plan of what we intended to do? Or shall we ignore that insight, sticking to the original plan even though inferior? Of course we will adapt! Anything else would be ridiculous.

An agile project anticipates that such insights will emerge, so its processes are designed to harness and leverage upon those insights: demos, retrospectives, re-prioritisation of product backlog etc. These practises are all aimed at constantly refine and redefine the scope. But then, we have derived from the original specification "all features and functions as initially specified".

Thus, any agile project longer than a sprint will fail - by definition. That is, if you use the Chaos rod for measuring success.

To put it bluntly, if you measure an agile project using the Chaos rod, it will fail. Either the agile process will fail, or the project as defined will fail.

Either, the project adapts to its measuring rod and blindly follows the "functions as specified", throwing whatever insight gained aside. Then, "project" will succeed, but "agile" will fail.

Or,  the project will work according to its agile-minded processes, and then certainly the result of the project will not be "all features and functions as initially specified". Then, "agile" will succeed, but "project" will fail. I e project will fail as measured by Chaos rod.

Damned if you do, damned if you don't.

A New (or Old) Hope

The good news is that the Chaos rod is not the only way to measure projects. As we have discussed earlier, there has always been two ways to measure projects: feature list (Chaos rod) or measuring business effect, what we can call the Effect rod.

Let us take our earlier example with an on-line book store. They had an idea that recommendations of the type others-have-bought would increase their sales, so they set of some money for that projects.

Using the Chaos rod they would have created a feature list around others-have-bought recommendations. The project would later be evaluated on how well it implemented the list. But let us look at a better idea.

Using the Effect rod they might set a target that customers will by 0.35 more books per checkout on average. The Effect rod is used to state the value of a project. These 0.35 books can probably be converted to money, that makes the project worth the effort.

The project might start out with an idea that others-have-bought recommendations would cut the cake. After the first small stories, deployed to production and put into hands of customers, the team learns that some kind of category would be helpful. To facilitate this they implement a simplified "search similar" as one of their features.

Suddenly the number of books in the checkout carts raise to a level 0.4 above the pre-project baseline. And the level sustains, it was not just random noise - the change is statistically significant.

The project has fulfilled its target according to the Effect rod, and is declared a success.

Measuring using the Chaos rod "on time, budget, and specification" - the project would have been deemed a failure, because it did not deliver the initially specified others-have-bought.

So, agile projects can be measured. You just have to use a measurement that is well suited. And, to be honest - which is better anyway.

A sad side-note is that I know of several projects which have worked in an agile manner, and delivered enormous business benefit - but in the project report the project lead has had to apologise repeatedly for not meeting the project target as defined in the project specification - a feature list.

Granted, to measure projects on business effect is not a new idea in any way at all. The idea was certainly there before the Agile Manifesto was written around the turn-of-millennia. What is new is that this way of measuring is essential to provide rigour to agile projects.

For Agile to succeed at larger scale, we certainly need lots practises around agile-minded processes. Measuring agile projects on effects is certainly one of them.

The way to measure agile projects is to set targets for business effect.

Yours

   Dan

PS Interesting enough, there is a sub-category "agile projects" in the later Chaos Reports, but the rate of success is not 0%, it is around 40%. I wonder what is going on here.

PPS Within the agile community, the practice of projects is debated - at least in the sense of the common description "temporary organisation with limited time, resources, and ambition". So, it would probably be better to use some other term, e g talking about "initiatives". However, for convenience, I have kept the often-used and familiar term "project". Check out the twitter hashtag #NoProjects.

Project Goals using Effects or Feature List

Dear Junior

There has always been two ways to set goals for a project, either you can define the goal of the project to be a list of feature to be implemented, or you can define some effect you want to see. Both of these have been around for a long time, and effect goals have always been superior. 

Setting goals as a feature list is actually pretty simple - you simply state "these features I want to see before we consider this project closed". An online bookstore could say that it wants search-by-author, categories, and others-have-bought recommendations.

Following up during the project will simply consists of checking how far on this check-list the development team has progressed.

Effect goals are a little bit harder to set. You have to figure out and express why you want to have work done, what purpose it fulfils, in what way it makes your world better. Said bookstore must then express that it hopes people each customer will by 0.35 more books per checkout on average, or that it will increase its customer base with 10 000 new customers.

Following up during the project using this approach will consist of measuring the business parameters and watch the values change. A tricky part is that the full impact of the project might not be seen until the development work is "finished" (whatever that means), or even not until some time thereafter.

To put things a little bit into context, it is not the "bookstore" that starts a project - it is always a person involved, in this case probably the product owner of the online store. And, this is the person who should explain why she is about to spend a lot of peoples' time and a lot of the organisation's money.

I have always found that measuring success on effect, or impact, is the more intellectually honourable approach. To be frank, setting goals as a feature list does really say "this much work I want to have done" or rephrased "this much money I want to spend", nothing about what value it should result in. And if you want to have a group of people to work to bring your ideas to come real, the least you can do is to explain to them the value you think it will bring. Setting goals on effect is really about that - bringing purpose to the work.

Now, these two ways of setting goals and measuring success have a fundamental impact on how to manage projects in an agile manner, but that will have to wait until a later letter.

Yours

   Dan

PS An agile project cannot be feasibly measured using feature lists; agile projects should be measured by setting a target for a business effect.

4 Points of Story Points

Dear Junior

For quite some time there have been a debate on "what story points really are". To some extent there have been insightful discussions about important things to consider when sizing stories. However, the "really are" part of the debate just leaves me tired. 

To discuss the true nature of story points is pretty pointless: they are a construct, created by us, and can be given any arbitrary meaning. It does not matter. What matters is whether that construct is useful for a purpose. This is the core of pragmatism.

In other words, the relevant question is not "what story points are", but "what story points are useful for". Please excuse the pun, but rephrased "What is the point of story points?"

If I try to pry things apart I can distinguish four different situations where I have found story points useful. Basically they cover the questions "Is it small enough?", "What does it cost?", "Which should we do first?", and "When can I have it?".

Small Enough

One of the cardinal faults a team can do is to start working on a story that is way to big. If they do, they will surely fail to finish it within the sprint, and having a demo with nothing to show is pretty depressing. Having a lot of half-finished work also tie their hands of what they can do next sprint. No good.

A mature team might have developed a gut feeling of how big a bite they can take and still eat it. The stories considered too big are simply sent back to product owner for delimitation or splitting.

A less mature team might see that bites have different sizes, but have not yet the insight of how big a bite they can take without choking. 

Here story points can come in useful. The team can size the stories as 13, 20, 3, 8 etc. But they need not to know their limits. Instead we can observe the velocity over a few sprints and see what "small enough" means. For example, if the team have a velocity of 18, I would advice to set the limit to 9 (half velocity). So, the stories sized 3 and 8 are small enough, and those of 13 and 20 will need some more pre-sprint work to make them manageable.

It can be handy to reserve the top of backlog for stories that are small enough, a "backlog shortlist" of ready-to-develop stories. Or, if you prefer the kanban style to have one stage "delimit and split" followed by a "ready-to-develop" queue before pulling them into active development.

Cost

Whether we like it or not, the question about money always come up. It can be hard to just look at a requested feature and say how much it would cost to develop it. In a lot of development efforts the dominating cost is the cost of labour. Either the work will tax the amount of available work by the employees, or there will be contractor bills to be paid.

Here story points can come in useful. Someone probably knows what the team costs per week, or can calculate it. If you have some historical velocity data you can make a rough estimate of what each point costs. So, if you know roughly the size of the story, you can calculate the cost.

Say that your team costs EUR 27 000 a week, you run two weeks sprint, and your sprint-velocity hoover around 18. Then each point costs around EUR 3 000. So, a story of size 40 will cost roughly EUR 120 000.

Well, not all of the time will be "pure development work". There will be meetings, phone calls, administration (filling out time reports) etc. But, that does not matter. Pulling through a story of size 40 will take roughly two sprints and during that time the team will cost that amount of money.

Of course, in practice you will rather want to give an interval than a precise number. The velocity might be within 17-19 (with 90% confidence) and a "40" story can be anything from 21 to 40. So the cost will rather be in the range EUR 60 000 - 130 000. Still, it will be a figure good enough for business to decide if it is remotely interesting to proceed or not.

Priorities

A misconception among business side "customers" is that they should set priorities on business value. Well, but "economics" is really about alternatives - the cost of a bar of chocolate is that you cannot get two lollipops. In the same way, for the product owner to make a wise balance between what different stakeholders want, she must be able to compare their cost.

Interesting enough, to make priorities, we do not need to know the absolute cost of each story. It is enough to know their relative cost.

Here story points can come in useful. If feature A is size 20, feature B is 8, and feature C is 13, then we know that we can swap out feature A from a release and switch in feature B and C instead. And in doing so we do not need to care about the details of how much money it is about - all we need is aid in choosing.

Planning

Business need to look ahead to synchronize different parts of their work. E g there are some benefits in having a marketing campaign at the same time as you release some new feature of your software. But, waiting for the software to be complete before ordering the marketing will obviously make you loose market-time. 

Here story points come in useful. If you observe the velocity of the team over some time you can apply some not-too-advanced statistics to predict how much work will be completed at some future point of time. Of course, each such prediction will have a probability to fail, and the surer you want to be, the lower you must set the prediction.

For example, if you have observed the velocities 36, 28, 36, 38, 24, 35, 32, 35 and you have five sprints to go, you can calculate the average and predict the team will finish 165 points. However, that prediction is just a prediction - the real result will be as likely to be higher as it is to be lower. In other words, your prediction has a confidentiality of 50 % - or a 50 % risk of failing. 

If you want to make a safer prediction, say taking just a 5% risk of failing, you can calculate an interval with 95% confidentiality. In this case it will be the interval 144-186. Now you can mark the backlog, colouring all stories up to 144 as green (very likely to be delivered), those from 144-186 as yellow (totally "depends-on") and those from 186 and up as red (very unlikely to be delivered).

In Summary

It is very hard to talk about the "true nature" of story points. They are abstractions that say something about development work. And, the question of "what they really are" is not a very interesting one. Working with story points is a model, and a model should not be evaluated on "how true" it is - but on how useful it is.

Story points might be useful for a team to decide whether a story is small enough to fit in a sprint, of if it should be pushed back to the product owner - if they cannot do it by gut feeling. 

Story points might be useful in assessing the cost of developing a story - if it is questionable whether its value justify the cost. 

Story points might be useful for setting priorities - if it is difficult balancing the stakeholder interests. 

Story points might be useful for planning at release level - if the organisation need to synch the work of different departments or groups

Apart from these four points, story points might be useful in doing other useful things - if it helps the organisation to act more wisely.

It might well be that in your particular setting, none of the "ifs" apply - and in that case story points are not useful to you. And if they are not useful, they steal time and attention from other things that would serve you better - i e they are waste that should be discarded.

In the end "what story points really are" is not as interesting as "what is the point of story points".

Yours

   Dan


ps Story points being helpful for planning is of course key to why release planning works.


pps If story points help in planning it is interesting to see what factors drive high story points. For planning, it is the amount of effort that differs, but that is to a large extent driven by the complexity.


ppps Unless you are really good at making statistical computation, it helps to have a spreadsheet to aid in the planning.


pppps One way to ensure team does not embark upon developing something "too big" is to make a backlog shortlist of the top part of the product backlog.

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

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