Technical Stories
As I recently wrote, I believe technical stories have a place in a healthy agile workflow, as long as we use them judiciously.
I left a question in that article unanswered: How do you get such stories into an iteration? An iteration can be fixed, like a two-week sprint or something more free-flowing like Kanban. In any case, the Product Owner is typically the backlog’s gatekeeper, which naturally leads to user stories having priority over technical ones. We have to live with that.
Trying to get important stories in play to see them deprioritized is very demotivating. Even more so if that happens again and again. The sarcasm level might increase. Dilbert comics might appear on the walls. Let’s see what we can do about it.
The bottomless pit of despair
I'm sure the ticket to fix that old bug is somewhere here
Much like rocks, technical stories are dense and tend to sink to the bottom of the backlog. They will remain there, forever, unless you fish them up like a treasure hunter. Many backlogs are living museums of ideas that are long obsolete.
Writing a story is the beginning of the journey. Don’t think your work is done after this! Until implemented, it’s just the illusion of progress. Our goal is to make sure that we regularly pick some of these stories alongside user stories and work on both. If that’s not happening, adding more stuff to the pile won’t help anybody.
No process will survive the lack of trust
Emerging trust-based relationship
I’ve been in many teams and worked with many different Product Owners. For some reason, negotiating the amount of bandwidth for technical work (or technical debt) is a classical friction source. There is something about wanting to upgrade to Rails’s latest version that brings out the darkest resentments of an otherwise functional team.
All those fruitless confrontations throughout the years have taught me that trust is an indispensable ingredient in this negotiation. I mean, trust is crucial in general. But in this case, you have some deeply technical topics that need to be merged into a very business-y roadmap (the backlog). If both sides mistrust each other, it’s bound to go poorly. No process will survive this.
As a Tech Lead, I often engage in these discussions. I have to admit that I’ve failed to build this bridge more than once. What to do, then? I could recommend something standard, like having empathy or being transparent. But you know that already.
A conversation starter
Finally, having invested all that time in creating sound stories starts to pay off. A story that provides clear context, has tangible value, and is clear about scope is much easier to sell than a poorly written one-liner.
Negotiate in good faith
The capacity of a team is a precious resource. It’s tempting to exaggerate the severity of a problem so that we get a bit more time to work on it. Hiding behind impenetrable tech jargon to prevent questions that we don’t have answers for might work once, but it’s not a long term strategy. We want to present stories that are clear on its purpose and give a picture of the value that we want to achieve. We want to have an honest conversation. That includes skipping work that we believe is important if there is no space for it at this moment. Only then we’ll gain the credibility to do so repeatedly over time.
Don’t be a pushover
Conversely, negotiation doesn’t mean capitulation. Some teams opt to avoid the confrontation, not pushing for any technical story unless the Product Owner brings it up herself. That will produce bitterness among the developers, who’ll think that they are not being heard. However, to be heard, you need to use your voice in the first place.
A healthy dose of continuous progress
Trust issues, conflicting priorities. It looks like an uphill battle! How do we know that we’re going in the right direction?
The most sustainable process is to invest a regular amount of work into technical concerns, every sprint. As my totally non-scientific chart shows, it should be a meaningful amount but not become the dominant theme. From experience, 10% to 25% is a reasonable number, although that changes depending on the context.
Why? Because small continuous improvements compound over time. It might not look like much, but it will make an impact. It doesn’t require extraordinary efforts. Keep the stories small. If you can prove that you can deliver small increments, it will create a positive cycle.
Also, be persistent. If there is one message to take from this post, it’s don’t give up. Every team I’ve ever been part of has had this discussion at some point. Without patience and perseverance, it always ends up in frustration. Angry people won’t do great work. Eventually, tech stagnation leads to user stories not being delivered, either.
Don’t bet on miracles
An anti-pattern that I’ve observed is to bet everything on one magical measure. One example is dedicating one full sprint to bug-fixing. Or hoping that using a new tool/framework while continuing the same process will fix every shortcoming. Not to mention the nuclear button: Let’s rewrite things from scratch!
It could work, I guess. But it doesn’t sound likely. And, more importantly, it isn’t sustainable. Are you going to do that next time as well? And the one after? Isn’t it just easier to make small improvements as mentioned above?
Conclusion
In summary, once you have your lovingly crafted tickets, you want to, you know, implement them. That is an essential and ongoing discussion with your Product Owner that has to be based on trust, transparency, and flexible negotiation. Your best bet is to create a continuous stream of technical work that gradually improves things.
Next Step: A technical backlog
After talking about writing technical stories, it’s the turn of getting them into an iteration. One thing remains: Which stories to pick? In other words, how do we maintain a technical backlog? That’ll be its own post.
Thanks to Anna for the feedback.
Top comments (0)