There’s always a fine balance to be found between making sure that your product is as buttoned-up as possible when it ships and the small (sometimes large) sacrifices that we have to ask our technical teams to make in order to just get the damn thing out the door. Within this gap lies the dreaded concept of “technical debt” – the ever-growing list of things that you know you probably shouldn’t have done or that you should have done, but that have way to the reality of getting product out to market. The good news? It’s not always bad. The bad news? Play too fast and loose with it and it will come back to bite you in the ass.
INVEST in Your User Stories!
I’ve touched on User Stories on several occasions, my favorite being Why Your User Stories Suck! Today I’m here to share with you a very common, yet very commonly overlooked, way to check each and every User Story on your backlog to see whether or not it’s really “ready” for your Dev teams. One of the most frequent causes of delays and slowdowns in most Agile implementations that I’ve seen comes from a lack of balance in the User Stories that the team is being given to deliver — stories that are too big, or which are dictates, or which just exist on the backlog because “someone asked for it”. What we need to do as Product Managers is to occasionally take a close look at each of our backlog items and make sure that they meet the INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small, and Testable. If we do this simple gut-check on a regular basis, we’re far more likely to see our teams succeed and to reduce the amount of time wasted in long, drawn-out planning sessions.
Leading Through Influence: Limiting Choices
I was working with a future mentee last week and we noticed a recurring theme to some of our discussions — that a large part of good Product Management results from limiting the number of choices that our teams and our executives have to choose from, so that they make decisions that reflect the actual priorities that should be driving our next moves. In most organizations, there is an almost unlimited number of ideas, concepts, directions, and motivations from which to choose — and trying to manage all of them at once is certain to drive any Product Manager insane in very short order. Rather, in order to ensure that we’re doing the right things at the right times, we need to be constantly limiting the possible permutations upon which we drive decisions so that we can be sure that we’re moving in the right direction while being open to new ideas and concepts!
Agile Roadmapping is NOT a Contradiction!
Many companies struggle with the challenges of reconciling the need for strategic planning and the desire to execute in an “agile” or Agile fashion. Generally speaking, this is because they’re stuck with the perspective that a “roadmap” must be a set of promises regarding what’s to be delivered, and not merely a strategy that will and must change over time. Being “agile” requires that we accept the unknowns in the world — and what’s more unknown than what the market is going to look like in 2 years? Therein lies the folly in trying to perform traditional roadmap planning and expecting to be able to be “agile” in your execution. But, there are some easy ways to change your perspective on roadmaps and maintain the balance between strategy and execution.
Why Your User Stories Suck
I find it ironic that one of the most fundamentally important aspects of Agile planning is so very often terribly implemented. User Stories are the single most important thing that a Product Manager/Owner delivers to their development teams — they’re the foundation on which everything the team does is gauged; and all too often, quite frankly, they suck.
The impact of the vast suckitude of these user stories is far-ranging, and does not go unnoticed. Bad user stories are one of the biggest causes of complaints on the part of development teams, the cause of endless friction and misunderstanding on the part of stakeholders, and ultimately result in missed deadlines, failed sprints, and Armageddon itself. Okay, maybe not quite that last part, but it sometimes feels like it.
Be careful what you put on your backlog…
We’ve all had the conversation…you’re working at your desk, just finished a call with a customer or prospect, and that random person comes around and taps you on the shoulder…
“Where’s my feature?”
“Huh? What feature?”
“You know — the feature you talked about last week.”
“Oh, that one! It’s on the backlog.”
“I know, so when is it coming out?”
“Well, it’s…on the backlog.”
“Yes, I know. So I told our biggest customer they’d have it next month, that’s cool, right? It’s on the backlog, after all!”
“YOU DID WHAT!?!?”
…and so it goes, and you wind up randomizing the teams to deliver what’s been promised, tossing out a good chunk of strategic work that you’d planned on doing.
Prioritizing in an Agile World: What’s Now, What’s Next, What Else?
While helping through a transition with a PM and Dev team that I worked with on a daily basis, one of the major stumbling blocks I ran into was Release Planning and Roadmapping. When I got there, they were in many ways using all of the right Agile terms, but not really following Agile principles – each release was meticulously planned out in advance, then chopped up into deliverable components that were split into two-week work increments. In private, I often joked that they were using “AgileFall”.