Don't lose control of your backlog

Have you come across a Technical Story Syndrome yet?

My product team is new to Agile, and in the early going developers fell in love with the formal user story definition. So much that everything they embarked on had to be first defined in this format. Before long my backlog filled up with stories literally like the one below:

  "As an XYZ developer, I want the benefit of a standardized API for storing (caching) items in the DC, as well as transferring (syncing) required items between the DA & DC, so we can improve development time by reducing the number of specialized APIs required."

For a typical Product Owner with background in Product Management this simply would not make sense, whether (s)he will care to admit it or not. An even better test, is showing this story to your customers. See if this interests them. Would they pay even a dollar for this feature? If not that's a sure sign we are dealing with the so-called technical story.

Developers will often insist that these technical stories help to make the product better. The problem with these stories however is that they cannot be ranked by the Product Owner in relation to other stories on the backlog, and if they cannot be ranked they cannot be ever worked on.

One way to deal with this is recognize the need for some proportion of team's capacity to be allocated to technical debt and simply include these technical stories there. In the beginning of the project this may involve some technical stories for building the plumbing, or the foundation of the product, later on the focus may shift to refactoring, performance optimization and defect resolution.

In my case I've created one technical debt story for each sprint, moved the technical stories underneath it, asked the team to budget for up to half of the available sprint capacity, and delegated to the team the decision on what needs to be tackled as part of this story (plumbing, refactoring, optimization, defects) and what has to wait till future sprint. Of course this is just a general guidance.

Once I placed a technical debt story at the top of the list, I was able to easily navigate my backlog and rank all the user-facing stories. Back in control I am!

In pursuit of the user story purity

As Product Managers we are accustomed to answering calls for better requirements, or better-written user stories as they are known in the world of Agile software development. It’s hard to argue with the logic behind this. Scrum teams can more efficiently groom their backlogs, decompose and size user stories and ultimately come up with better fitting winning solutions that keep our customers happy and revenue flowing. 

Let’s take a look at one approach meant to raise the bar with this. A scrum team was instructed to re-visit stories on its backlog using the following WHO, WHAT, WHY and HOW framework.

·      “WHO” … this speaks about the importance of defining the end user for the requested capability.

·      “WHAT” … the approach argues it’s important to define WHAT in terms that all scrum team members understand.

·      “WHY” … if you don’t frame the WHAT in a WHY, different scrum team members will each interpret a different reason, which will lead to very different solution approaches… “As a car operator I want a cup holder in my car so that I can store my loose change in it for tolls” is different than “I want a cup holder in my car so that I can drink my beer while driving”.

·      “HOW” … should simply stay out of user story definition, i.e. left to the team.

I have to say some of the discussions around user story descriptions were quite enlightening as they helped everyone on the team better understand the need and the scope of what’s requested. On the flip side, I've also encountered what seemed like recursive looping, where the scrum team having quickly agreed on WHO, endlessly circled between WHAT and WHY in the search of ultimate answer.

Take for example this wild goose chase:

• As a middle-aged daily commute driver I want a cup holder in my car so that I keep spare change there to pay for my tolls.
• As a middle-aged daily commute driver I want easily accessible place to store change in my car so that I don't scramble at the tollbooth.
• As a middle-aged daily commute driver I want a convenient, stress-free way to pay for my tolls so that I can enjoy my ride
• As a middle-aged daily commute driver I want to enjoy my ride because the life is short

… You can see where this can lead J 

At the end of the day PO defines the requirement in the form of Agile user story, based on his/her knowledge of the market and application domain. Time boxing these discussions is all it takes to ensure your team spends just enough time to understand well enough what needs to be done to be successful.

Roundtable with Ken Schwaber

Last week I attended a roundtable and presentation by Ken Schwaber, one of the two original Scrum process developers and signatory to the Agile Manifesto. He reminds me of Steve Jobs – same black sweater with round neck, grey hair sprinkled here and there… somehow this image adds to projected credibility and I wonder if Ken is aware of this.

A few takeaways...

1) Scrum team is all about the team, not the individual. The way Ken drove this point across brought smile to my face however - he essentially appealed to the virtues of socialism, how irrespectively of the talent and abilities everyone should be rewarded equally. So, everything I've heard in my childhood was not that bad after all, just Agile way of doing things?! hehe… I just can’t imagine this philosophy really taking roots in the American culture.

2) I found Ken’s way of talking to the audience about Product Owners (POs) refreshing, particularly in the room filled mostly with developers. For example, Ken points out how scrum teams he interviews often complain that POs don’t write good enough user stories for them. Ken concedes that writing user stories is not necessarily the biggest value POs bring to the table. He states it’s the team who should write, or rewrite if necessary, the story, as long as it still represents what PO believes is a market need. POs should maintain focus on bringing the voice of the customer to the table. They define release vision for the team and ensure backlog prioritization reflects it, often making high impact tradeoffs based on the information available to them at the time.

3) Finally, Ken is questioning the whole notion of scrum team’s commitment to deliver a given number of user stories during sprint planning sessions. He reasons that all too often people interpret this commitment as a guarantee to deliver… irrespectively of quality, which takes us all the way back to the world of waterfall planning. What Agile strives to ultimately achieve in software development is to take out the false idea of being able to plan the unknown – the time it takes to innovate. Ken suggests replacing the term “commitment” with “forecasting”. Contrast: “Team Jedi commits to deliver user stories X and Y” vs. “Team Jedi forecasts to be able to deliver user stories X and Y”. In my experience I found teams, particularly recently formed with limited history of working together, tend to err on the conservative side of committing to fewer stories precisely because of the fear of not delivering on promise. The notion of forecasting may help free us from that mental cushion we learned to use over the years, to pad our effort stimates in traditional waterfall project planning.

All in all, the presentation was educational and inspiring. Thank you, Ken. It was great to hear your perspective on how Scrum is being adopted by other teams, and see you striving to keep abreast of our changing world and how people embrace the change. After all, as you suggest - Scrum is really about understanding and managing the change!

P.S. I look forward to reading my signed copy of Ken’s recently published “Software in 30 days” book.

The guilt of not doing it all

I recently had a privilege of spending a few days with a large group of highly successful, talented managers and I asked them one question: "How do they deal with the pressure or even a certain sense of guilt of leaving something undone when they realize that certain things on their plate are not as important as something else?" Below I share some of the answers I collected along my own ideas inspired by this encounter.

• Minimize time spent in reactive mode
• Schedule time on your calendar to work in reactive mode, specifically to work with email. Communication tools such as smartphone, instant messaging and email are the most common sources of reactive mode of operation, so restrict times when you allow yourself to access and use these tools.
• Try to avoid sending emails off hours. This will only encourage others to operate and expect you to work in reactive mode.
• Prioritize, prioritize, prioritize. 
• Maintain a list of priorities on a regular basis
• Focus on what you can finish in a day
• Force yourself not to jump to action right away when tasks appear on your plate, artificially push them off, let them either earn the right to be worked on or gradually fade off your list.
• Recognize false urgency by examining and understanding who and in what way will be impacted if you don't do this
• Take a risk, learn to say NO
• Just because someone invites you to a meeting you don't have to accept. Decline and see what happens.
• If you find yourself in a conference call that goes nowhere, your contribution is minimal/questionable, and you are multi-tasking on something else, excuse yourself and hang up.
• 2-5 minutes before the end of a scheduled conference call, remind participants that time is running out and hang up when the time expires. 
• Delegate whenever you can, even if you don't have direct reports
• Learn to recognize which tasks can be matched with someone in your organization who can accomplish them.
• For repetitive things that routinely get onto your plate, seek to adjust the process
• Share with your leader, manager, mentor. Be open and honest. Seek advice.

Difficult customers?

Not letting occasional unconstructive snaps from our customers rattle us and keeping communication channel open (friendly, forgiving, etc.) in the grand scheme of things will serve us best.

For starters what we hear will broaden our horizon and may teach us new things or let us connect the dots in our head in a new way.

Not everything customers ask us to do is best for our product. Listening to customers doesn’t have to automatically translate to action. It's all about acquiring as many data points as we can, even if these are low quality data points. ...just keep fishing.

Finally, it's not uncommon to see highly critical, skeptical customers eventually turn into most vocal and passionate advocates of our products, thanks to not giving up on them at some point.

Realize how others perceive you

Considering we don’t really change personality-wise over the years, it comes as no surprise that our communication style often remains essentially the same as we grow in our careers. I recently realized however that the role we play in the organization has a great impact on how people interpret our messaging. Consider how the same brisk but honest statement from junior engineer “we have to do better, our UI is too clumsy” would come across very differently from a senior manager...

Have you noticed how as people move up the organizational ladder their written communications become sparser, particularly when addressed to multiple recipients, ultimately disappearing completely or becoming outsourced to professional aids? Could this be driven by the fear of being misinterpreted?

Are we there yet !?!

With almost any sufficiently important project executives (or investors) want to keep a close eye on the progress made. As the project nears completion and the product launch looms ahead tensions may raise as uncertainty of successful outcome builds. See if you recognize this inquiry Product Managers may be responding to near the project end:

"As the owner of the backlog, how do you evaluate the priority? Do you have things such as must have vs wish for? Each time I have released a new product to market, there are always more things to do...it's a universal constant.

What I am looking for is a report that tells me how much of the backlog is customer driven/validated (required to be competitive in the market) vs. what folks desire. If we had a report that could provide insight into the health of the offering....not sure what metrics I would want to see, but I am sure I would like to know if the epics we started out to build, are creating the value we envisioned (i.e are market ready)."

 
In traditional requirements management, requirements are often categorized at 2-3 levels (e.g. Must/Important/Wish or High/Medium/Low). In Agile we are taught to rank them (user stories) from 1 to N, so if you have say 100 requirements ranked from 1 to 100, you may have only 10 show-stoppers - requirements that you believe absolutely prevent you from launching your product, or you may have 80 show-stoppers. In one case you are very close to be able to confidently launch your product, in another case you are probably quite stressed out.

So how do you know when you are truly ready to launch? Are you getting closer to that point, seem to be standing still or are actually drifting away?

Agile forces us to worry less about "launch readiness" in favor of most efficient utilization of available resources. In other words, as long as our teams (fixed resources) always focus on top priority (as defined and adjusted by Product Owners in timely fashion) issues there is nothing we can do... other than recognizing when we are not ready to launch.

There lies one challenge many Agile projects have to deal with: when the launch date is "artificially" fixed in advance the product team is like an airplane crew forced to land irrespectively whether the landing gear is down or not, without regard to weather and airstrip conditions. Should the crew be able to decide when is the right moment to touchdown, or in response to 1st class passengers "Are we there?" just strap on the seat belts and hold tight?

So in recognition of the need for transparency, how can we indeed bring more clarity to our progress on the final approach, without causing unfounded panic in the main cabin? :-)