Stalled Stories

When I arrived at a startup software division, the story-writing process was virtually stalled. A young woman with a strong personality and backed by the authority of her executive father was vying for control with the more experienced Pharmacy Technician that was charged with supplying User Stories to the development team. The female tech, acting in the Product Owner role, liked the younger woman and even considered herself the junior’s mentor, but the tug-of-war against the stronger personality impeded progress.

As someone with significant project scar tissue, I was inserted as Sr. Business Analyst and was able to help them break the logjam. To the younger woman, I became the keeper of the product backlog and her story reviewer. She could submit detailed written stories of interest that I could include in the product backlog. To the more experienced tech, I became a sounding board for her more verbal approach to story writing. She wanted a partner to bounce ideas off of and someone to validate her own thinking before submitting a story in writing.

What made me effective in a situation where two others were stalled? I respected and agreed with both of them and refused to lock horns with either party. Instead, I offered gentle suggestions here and there, allowing each of them to write stories from their own perspective. I have learned that it is much easier to say ‘yes’ to feature requests than argue about them up front. Customers have limited budgets and limited time. In the end, it is these larger constraints that determine which features get included in a product. The most valuable features tend to bubble up in the list of priorities and get worked on. The least valuable often sink down and fade into oblivion. After all, a product backlog does not have to be empty when the project is done.

User Story Showdown

One day I was reviewing a list screen in the development den and hit a brick wall. The application queue page had been developed by the senior architect of the team, a bearded philosopher type who had deeply absorbed the agile mantra to ‘maximize the amount of work not done.’ For this fellow, the answer was automatically ‘no’ until you made your case. I’m sure you’ve met one or two of these in your travels.

The screen in question was a list of transactions and they had some common attributes. That is, multiple lines could have the same description or the same type. Anxious to make what I thought was an easy improvement, I suggested that we add a ‘Row’ or ‘Item’ number column – something that the user could click on to open that row. The architect insisted that any other column could be used for that. A new column was not needed. The identifier column was indeed added to the list, but not that day. That day I left the room with hurt feelings and an important lesson in hand.

I failed to make the case for the new column. The change seemed logical to me (and, in fact, was) but I approached the feature based on my own desire and experience rather than bringing the team a value-based User Story that carried the weight of a real stakeholder. It is a lesson I would repeat until I fully embraced the principle that development team members are not application stakeholders. Only the voice of a real customer carries authority in a feature User Story.

Is Your Agile Team Stalled?


Do you feel overwhelmed? Are customers or stakeholders complaining? Has team velocity tanked?

Don’t feel bad. These problems are quite common in custom software projects – and they are solvable. The good news is that technical complexity is probably not the issue. It almost never is when a project has trouble. No, it’s much more likely that you have a problem in one of three areas:

  • Lack of authority
  • Lack of transparency
  • Fear

Those don’t sound like technology problems, do they? Alas, we (people) get in our own way and cause most of the problems you see on software projects. But instead of focusing on the problems, let’s look at the positive ingredients you need to win the custom software game:

Strong Product Owner

The Product Owner (PO) carries the vision for what your product should become. To be effective, they should be:

  • Knowledgeable
  • Empowered
  • Available
  • Collaborative

A strong PO will feed the team a set of features that have been prioritized by business value, make decisions quickly on behalf of the company, be available for questions, and invest in the team’s success. They constantly work ahead of the development team, clarifying requirements and ranking features so that the team never runs out of work that is valuable to the customer.

Transparent Process

Everyone on the team should be able to quickly answer these questions:

  • What are the most important items to work on?
  • When is the next delivery expected?
  • Who is working on what?
  • How is our progress?
  • What is in our way?

Teams that cannot answer these questions spin their wheels and waste time. They also frustrate management by creating a shroud of mystery around what they are producing and when. The team needs a proven pattern to follow so that everyone marches to the same delivery drum. This is what the Scrum ceremonies provide. They bring structure and focus without micromanaging your talent.

A Safe Place

Tension seems built into software development.

On one hand, there are stakes to the game we play. Money can be wasted. Market opportunities can be missed. Jobs can be lost. We must extract maximum value from our talent investment. We must also safeguard the public and customers and whoever else could be affected by our work. We might not work at a nuclear plant or in the ER, but there are still important matters before us.

On the other hand, software is built by people. We want to be liked, to have respect, to feel connected, to experience mastery, to contribute. Some days our foibles are louder than our strengths. We have a deep-seated need to be heard and to be understood. We fear rejection and the disappointed look.

Balancing these concerns is a delicate dance. A hierarchy of principles must be applied. People are more important than projects, generally. But personal issues must give way before a looming team deadline. We are always balancing and rebalancing the people-vs-performance equation. Wisdom cannot be reduced to a formula.

Taking Action

While our typical project problems are solvable, they are not trivial. Pareto tells us to move the biggest rocks first in order to get the most progress:

  1. Make sure the team has a stack-ranked list of valuable items to pull from.
  2. Give them a proven, repeatable development rhythm to follow.
  3. Increase collaboration and idea flow by safeguarding team members.

Photo credit: Wayne Stadler Photography via / CC BY-NC-ND