Previous month:
October 2018

What’s in your backlog?

Let’s explore what you do and do not put in a backlog. How do these sound?

  • Features and non-functional requirements – Absolutely
  • Bug fixes and change requests – Yes, probably
  • Risk avoidance and risk reduction activities – Sure, maybe
  • Opportunity exploitation activities and marketing ideas – Now you’re just getting weird!
  • Team building and social events – Erm, no!

Yet, if it’s all just stuff for the team to do, then why not put it in the backlog? Maybe because the customer has not asked for it and the product owner has to own and order it, but let’s look further.

If we used a backlog metaphor for prioritizing backlog work items. It may look like this.

Backlog of Backlog Items

I am not suggesting these are the correct elements for including in a backlog, I am just showing the common ones. However, I am probably getting too abstract too quickly. Let’s start at the beginning.

A Backlog Primer

For agile teams, backlogs represent their To-Do list of work. All the things they need to complete before the product or project is done. Now, there may be interim releases. In fact, there should be interim releases delivering valuable functionality as soon as possible. However, there typically remains a list of remaining work. For long-lived products this list may never be emptied by the team, instead it is refreshed and reordered based on the latest priorities.

While the team works from the backlog, it is typically prioritized by a product owner / business representative / ambassador user that sequences the work. This product owner manages the backlog, keeping things up to date with the latest product decisions. They also flesh-out items prior to work starting on them. Product Owners also answers questions about the work from the team, etc.

Here’s a typical backlog showing a combination of features, change requests, bug fixes and a couple of risk reduction activities.

Backlog example

Types not Granularity

This post discusses the types of things in a backlog, not the names we give different levels of granularity. Big chunks of work might be grouped into releases and then divided into themes, or features, epics, user stories and tasks as they get smaller and smaller. There is not an agreed to hierarchy at the large end of the spectrum, often teams miss out one or two of the theme / feature / epic options. However, most teams use the user stories and tasks as work gets smaller.

Nevertheless, this post is about types of work, regardless of their size or what we call them.

Scrum Product Backlogs and Sprint Backlogs

Your view of a backlog may be different from mine. Most people I meet these days were introduced to backlogs through Scrum.

The Scrum Guide describes the product backlog as an ordered list of everything that is known to be needed in the product. It is also the single source of requirements for any changes to be made to the product. The guide goes on to describe the sprint backlog as the set of product backlog items selected for the sprint, plus a plan for delivering the product Increment and realizing the sprint goal.

My backlog history goes like this…

“It’s All Just Work We Have to Do”

I was first exposed to backlogs of work in the early 1990s. Working as a developer at Data Sciences Ltd in the UK I wrote a program to manage our work tasks on a government project. My project manager saw it one day and two interesting things happened.

  1. He did not chastise me for working on a side project of developing a visual work tracker rather than working on the client project.
  2. He asked why it did not contain all our bug fixes and change requests? I did not have a good answer, other than those are different buckets of work we should track separately. He dismissed this explanation and told me to add a flag if I wanted to track work types separately, and said “It’s all just work we have to do” and walked off, but his insight stuck with me. The class of work is secondary – all this stuff needs to get done.

My visual work tracker was quite limited and I abandoned it. The database connection from Easel (a language better suited to building graphical UIs for mainframe systems) did not support concurrent users well. Yet, a couple of years later when we started creating DSDM I knew the backlog was “Just work we have to do”. The backlog is the input-hopper for team work. The product owner is the input-hopper custodian, often subject matter expert, and settler of priority and compromise disputes / negotiations.

 

Risks in the Backlog

I have been keen on proactively addressing risks for many years. Just as features deliver value, risks in the form of threats to the project cost money and cause delays - if they occur. As such, these threats are potentials for anti-value. Like bank deposits and bank-fees, the act of adding value and avoiding losses go hand-in-hand to maximize value.

In the late 1990s I used RUP with some clients and was impressed by the Elaboration phase’s goal of tackling risks early in the project lifecycle. I corresponded with Philippe Kruchten, co-author of RUP, about how to illustrate the good work done on risk reduction during Elaboration that often did not have a lot to demo or show for it. I ended up creating Risk Burn Down graphs for my projects. I wrote about these ideas when I started blogging in 2006 as Risk Profile Graphs. By this time I’d been using them for 4-5 years and knew they were well received by sponsors and executives.

Later in 2006, I wrote about risk adjusted backlogs and Agile Risk Management explaining how to insert risk avoidance and risk reduction activities in the backlog. In 2012 I presented some Collaborative Games for Risk Management at the Agile 2012 Conference and PMI Global Conference. 

When members of the project management community read these posts and papers they correctly criticized my ignorance around proper risk management terminology. Risks, of course, can be positive (opportunities) or negative (threats). I was only talking about negative, potentially harmful risks (threats) when I talked about inserting risks based activities in the backlog. A real risk-adjusted backlog has both threat avoidance and reduction steps, as well as opportunity exploitation and opportunity enhancement actions.

This is how we got to risk avoidance and opportunity exploitation activities in the backlog.  One aims to avoid costs, the other aims to generate new value. Risk management techniques like Expected Monetary Value converts probabilistic events into financial values. For instance, if we have a 50% risk of incurring a $400,000 loss then this event’s expected monetary value is 50% x $400,000 = $200,000.

Likewise, we can assess opportunities too. If the average profit for new customers is $20,000 per annum, then we can determine if inviting qualified applicants on a factory tour with product demos and giveaways that costs us $500 per head is worth it at a 5% conversion rate. Here $20,000 x 0.05 = $1,000, so yes, it appears worth offering factory tours and giveaways for qualified leads.

Multiplying guessed benefits or losses by guessed probabilities is an inexact science. However, it is one that the insurance industry has spent centuries trying to master. So they err in their favor and often price based on what the market will bear. Yet it happens throughout all forms of business and is the basis for taking an economic view of production that underpins all the return on investment and prioritization schemes such as Weighted Shortest Job First. We are constantly looking to maximize value.

So, if a team building lunch is important for boosting performance or reducing the likelihood of conflict and delay, why not put it in the backlog? If it would be helpful for someone to walk the VP of sales through the latest product demo, put it in the backlog.

The Product Owner remains the custodian of the backlog, but with some discussions around threats and opportunities, they often see the advantages of adding these other work types to the backlog. Taking an economic view of work allows us to decide “Where is the next best dollar spent’. That may well be on Feature X or a site visit to help build relationships and increase motivation.

 

 


Certification Proliferation and Confusion

Cert ProliferationLike TV channels, the choice of project management credentials has exploded recently. 20 years ago things were much simpler, in North America, the PMP was the dominant credential, in the UK and ex British Empire countries it was PRINCE2. Life was straightforward, career paths defined, and credentials well understood.

In 1983 in the US, over 100M people watched the finale of the TV series M.A.S.H. Outside of the Apollo moon landing and sports events, it remains the most watched US TV broadcast of all time. Chances were most people in the office watched it and everyone had something in common to talk about. That was Peak TV, viewer counts have increased since but program choice has exploded much faster. These days there are so many cable choices, on-demand services, YouTube channels, and Periscope sub-streams it seems as if everyone watches something different.

Likewise, project management credentials have proliferated too. Today I discovered 7 different credentials for PMO staff from the same provider. Each (presumably) providing some niche specialization or incremental progression from a former step. Don’t even get me started on Agile certifications which have splintered and multiplied faster than the brooms in Fantasia’s Sorcerer’s Apprentice.

This creates problems for project management professionals and hiring managers alike. How can they compare or rank one over another? Within the PMI community, people know the CAPM® is a foundational credential and the PfMP® is more advanced. However, outside the PMI the situation is complex and rapidly evolving.

Becoming a Certified Scrum Master might sound impressive, but for many people, it merely required attending a two-day class. Yet, at the other end of the spectrum, the Association for Cost Engineers (ACostE) requires degrees or over 30,000 hours of experience (3 times Gladwell’s 10,000 hours guide). This is more like a career quest, rather than a 2018 learning aspiration. 

This diversity in experience requirements and study effort along with frequent new offerings muddies the waters of comparison. It would be negligent to simply ignore new offerings since many have been created to fill real needs.

Instead hiring managers likely use unknown credentials as a demonstration of lifelong learning and career change motivation. They may not know exactly what they entail, but for promising candidates, a few minutes on Google should shed light on the credential requirements and process. Unfortunately with the rise of automated and AI-assisted recruitment workflows these candidates might not make the initial selection due to keyword filtering.

If someone was a little sneaky I guess they could state on their resume that their New_Credential_ABC was similar to a PRINCE2 Practitioner, PMP®, or another credential so they pass the keyword scan. Yet, if you were so inclined, you might as well have a section called Future Credentials Planned and list them all along with your Nobel Prize.

It is unlikely TV channels or credentials will ever converge back into a simple collection of universally understood offerings. People want choice and specialization.

If the future of recruiting really will be AI driven maybe a service that ranks, validates and checks credentials will be created to remove the need for hiring managers to do so? It could be constantly updated and evaluated by independent experts to ensure parity. In the meantime, if you have a niche credential or are considering pursuing one, be aware its lack of recognition could be a factor.

Ideally, credentials are just an entry point, beyond which experience and character fit are evaluated. Hiring managers should look for a baseline proficiency but then focus the bulk of their decisions on soft skills evaluated through interviews, etc. We could say it is like making sure candidates have a driver’s license if a job requires driving, it is a prerequisite. Yet we know hiring managers attribute more credence than this.

It is because of this proliferation of credentials and the encouragement to renew and expand that some people are opposed to them. They believe they are money-making schemes for the owners and not reflections of ability or experience. I sympathize to some degree, as stated, at best they are entry points, like drivers licenses, that demonstrate a base level of competence. Yet they are used by hiring managers to qualify candidates. It seems if you are looking to change jobs they are, to some degree, a necessary expense.

For other people, credentials are pursued for personal reasons. Maybe to encourage ongoing development or for differentiation among peers without changing jobs. The list of motivations for pursuing credentials is likely as diverse as the credentials themselves.

More choice is great - until it isn’t. When options and complexity overwhelm our decision-making process we need new tools. Luckily we can learn from other arenas that have complexity. The internet has not unified and standardized the choice of news, entertainment, or services. It has done the opposite and created more choice, enclaves, silos, and choices than ever before.

Fortunately, the internet also comes with tools to search, sort and rank to help us navigate all the diversity.  We need the same with certifications. As television and films proliferated sites like IMDB, RottenTomatoes, Fandango, and Metacritic were created to add smarts and help us choose. Built around expert and personal ratings these sites allow people to sort, filter and view aggregate scores.

Hopefully, we will see the same with certifications. Hiring managers and people looking for the next credential to consider will have tools to help them choose. Whereas films and TV shows are filtered by genre (action, adventure, drama), actors and viewer age recommendations, certifications will have different criteria. Categories such as topics covered, experience requirements, and assessment method are some basic measures. Beyond that user-provided data on market awareness, average study effort, typical salary bands, etc. could be added.

Just as we will not be reverting to only 3 or 4 TV channels again, we cannot expect the diversity in credentials to disappear. Unpopular ones will fail, but more choice seems to be the future. Fortunately, the solutions for managing complexity and too many choices have been modeled in other domains.

Currently searching for “Best PM credentials/certificates/qualifications” yields lots of articles, but no community-sourced tools. That’s likely the future and maybe a project for one of our readers?

 

References:

  1. UK Project Management Market Snapshot, October 2018 – Arras
  2. Wikipedia: List of most-watched television broadcasts, Retrieved October 2018
  3. Project Management Certification Benchmarking Research: 2015 Update - Dr. Paul D. Giammalvo

 

[Note: I wrote this article first for ProjectManagement.com here]


GOAT18

Shaw-center_0I am excited to be a keynote speaker at the Gatineau-Ottawa Agile Tour (GOAT) conference on November 30th. Along with Mary Poppendieck, we will be leading a day dedicated to learning about agile culture and collaboration.

The Gatineau Ottawa Agile Tour is an annual conference in the heart of the nation’s capital, focused on sharing and learning. GOAT has run for 7 years and is part of the Agile Tour that takes place in 90 cities worldwide.

Click to see the Keynotes Overview and the Sessions Previews.

I hope to see you there.