Getting DEEP with your Backlog Part 4

Prioritization should NOT be stressful

This is the last of our discussions to help product owners manage their backlogs better.  We have covered making a backlog detailed appropriately, estimated, and emergent, this week I want to talk about making the backlog prioritized.

The management consultant Peter Drucker said, “First things first.  Last things never.”  What this means is you do what is important and then ignore the other things.  Since becoming a scrum master, I have lived by that mantra and I think it should also be a helpful guide for product owners.  In my experience, I have seen backlogs filled with hundreds of stories of "nice to have" features.  Many of these stories are never worked on and the backlog gets larger and larger creating a sense of futility on the part of the development team and the product owner.

I am also personally surprised by how many people in leadership roles who can’t prioritize.  For example, I asked a person to pick one of two options.  They were so paralyzed by fear and uncertainty that they instinctively said, “I need to ask my manager.”  When I pressed them to make a choice, they said “…can’t we do both? They are both important.”  The reality is that both choices are not as important.  They both need to get completed but objectively they cannot be done at the same time so which of the two choices should we do first.  This creates spasms of doubt from some people.

What I suggest to some product owners is make a list.  Then they number the items in the list based on priority. No two items can have the same value.  If you can’t decide the value of two priorities because they are similar, flip a coin and give the winner a higher priority.  If they are that similar, then the time spent fretting over which is more important is going to cut into the time you could have spent getting work done.  Get the work done; it is easier than explaining why you didn’t get the project done on time or budget.

A good product owner needs to understand what it takes to get a software product into production and what the business needs in order to make it successful.  They also need to make hard choices and set the order in which the work gets done.  They also need to say which work can be ignored.  If a story has been lingering in the backlog for three years and no one has worked on it then it needs to be dropped.  If it was not important three years ago then it certainly will not be missed today.

Your back log can be organized in numerous ways but the most important is by priority.  Do the important things first and provide business value right away.  Then you can focus on the Vice President's pet project after the sales figures improve.

So there you have it, Roman Picher’s DEEP model of managing your backlog.  The backlog should be detailed appropriately, estimated, emergent and prioritized.  It was fun writing this series and hope you got some value from it.

Until next time.

Getting DEEP with the Backlog Part 3

Riddle me this?
What is an emergent backlog?

This is part three of our four part series about how to make your backlog better using DEEP principles.  This week I want to talk with you about the third practice of getting a better backlog.  Together, we have covered how the backlog needs to be both detailed appropriately and estimated.  Today, I want you to cover how the backlog should be emergent.

The word emergent has become code in the agile world for “we have not figured this out yet.”  The truth is that when you are a product owner or a business you have vague ideas about what you are looking for but you don’t know the specifics of how to get there.  In the spirit of the age, we should talk about super-hero movies and the character Batman as an example.  Batman in the 1960’s had been around thirty years, so when ABC wanted to adapt it for television they could have taken numerous directions with the character.  They decided to make the series “campy” and appeal to children.

Today, the character of Batman is very different with a dark and grim edge based on the origin story of the 1930.  I happen to be a particular fan of Michael Keaton and his portrayal of the character in the late 1980’s.  That Batman is a different character from the one which Adam West made famous.  This is because the writers and producers made numerous choices along the way so that they reached a different narrative point.  As a product owner you will do the same thing.

What this means is that you will not have a finished software product which will emerge from your requirements like the great American novel.  Instead, you are going to have many small chapters in a long story and you will be able to inspect and adapt the story based on the situation.  This is why a backlog in the words of Roman Picher is emergent.  You are not sure how the project is going to end until you are finished.

This does not mean you don’t have a plan.  It means that instead of one great big product you have numerous small products which together make up a unified whole.  The product emerges from the individual stories and from the sprints.  So for your backlog to be successful it needs to be detailed, appropriately, estimated and emergent.  Next time we will talk about the final principle of DEEP.

Until Next time.

Getting DEEP with your backlog Part 2

Estimation is not rocket science

Last week, I began my discussion about how to be a better product owner.  I am using Roman Pichler’s DEEP approach to making the product backlog more useful.  Last week, I discussed how a backlog should be detailed appropriately.  This week I am covering estimation.

Estimation has gotten to be a dirty word among many technical professionals.  They are treated as quotes by business owners.  Estimates are often lies we tell ourselves and employers about how difficult a task can be.  So as a product owner, when you ask a development team to estimate you will often receive eye rolls and sarcasm.

The reality is, if estimation is done correctly, it can be a useful tool in planning work.  Each time a story is authored and placed in the backlog, the development team should attempt to estimate the story.  If the story is not detailed appropriately, the story is stent back to the product owner to be further refined.

If a story has enough detail them team should estimate it with story points.  Story points are a function of difficulty of a task and the uncertainty surrounding it.  Don’t consider it a measure of time but treat it like a measure of distance.  An Olympic runner can run a mile in under four minutes.  A man like me can walk it in about thirty minutes.  Considering the wide range of skills on many development teams, I may take one developer eight hours to complete a story point and it will take a different developer four.  Time is not the issue because complexity and uncertainty are the key factors.

Once a team begins estimating stories, you can experiment with team velocity.  If your team can do between 30 to 40 story points a sprint with a little simple arithmetic you can project out how long it is going to take you to finish.  For instance, if you have a 150 story point in your backlog in a worse case scenario you know it will take five sprints to complete the work while it will take four sprints in the best circumstances.

It may not be realistic for the team to have each story estimated so the rule of thumb I have discovered is you should have two sprints of work estimated.  You will have a good flow through the project.  You will also be able to answer the question your business partners care about most; when will the team finish and how much is it going to cost.

So that is why a product backlog should be estimated because it makes it easier for a team to budget its work.  An estimated product backlog also allows you some ability to forecast when the team is going to finish its work.  Finally, estimates are not hours treated as a quote but rather points which are a function of complexity and uncertainty.

So by having a backlog detailed appropriately and estimate you are going to be more successful as a product owner.

Until next time.

Getting DEEP with your Backlog part 1

Product Owners need to get DEEP.

The hardest job in the technology world is the job of product owner.  At my firm and others, the product owner is an afterthought to an agile transformation.  They are usually a business analyst or a mid-level employee working in the department needing software and then they have to spend half their time doing their full time job and then the other half writing user stories and trying to understand how software gets constructed in their organization.  So this week and over the next four weeks, I am going to offer some helpful direction to people who find themselves as product owners.  We are getting DEEP in the month of April.

I am a big fan of Roman Pichler’s book “Agile Product Management with Scrum”.  This series of blog posts is going to draw heavily from his work on how to be a good product owner.  In the agile world there is a social compact.  The product owner sets priorities for what work gets completed.  The development team says how long it will take to do these priorities.  When the work is done they have a retrospective to assess what can be done better and faster.  Then the entire process starts all over again.  In order for this to be successful, the product owner has to create a backlog of work which follows the DEEP model.  A product backlog has to be detailed appropriately, estimated, emergent, and prioritized.  This week we will talk about how a product backlog should be detailed appropriately.

A backlog is nothing more than a series of user stories.  At a start-up or small business a user story can easily fit on a post it note or index card.  At a fortune 500 company requirements are often giant binders with mind numbing detail.  I feel there is a balance between the two extremes.  A user story should be in the following format and it is familiar to most people in the world of scrum:  As an "X " I want "Y " because of "Z".  This is the one sentence mission statement for the story.

Next, a user story should include the definition of done.  I have discovered that the best way to get developers and business people to effectively communicate what needs to be done is to use something from the world of test driven development: given, when, then statements.  The GWT syntax or Gherkin language is a perfect means to communicate what it means for the user story to be complete.  It also makes it possible for a developer to easily write unit and functional tests speeding up development in the long run.  When the development team reviews a story, I usually demand that stories include GWT statements for both affirmative and negative situations.  This way we avoid a lot of recriminations during the retrospective when a product owner says we did not finish our work.  A given, when then tends to clarify what it means to be done.

So each user story in your backlog should include a mission statement of what needs to get done, and enough GWT statements to cover positive and negative outcomes.  UML diagrams, attachments of XML, and wire-frames are helpful but not necessary for a story to be detailed appropriately.  As a scrum master it is up to you to train the Product Owners to have user stories which are detailed appropriately.  Next week, we are going to cover what it means to have stories estimated in a product backlog.

Until next time.