Steve Tooke

Thoughts and things

#UserStoryAntiPatterns

Problem

The team are asked to define the User Stories for an upcoming initiative.

Context

  • The team / organisation are undergoing an Agile transformation

Forces

  • There is an expectation that the User Story template be followed
  • The team believe they have already have lots of customer knowledge
  • Product Owner has a strong engineering background

Supposed Solution

Create the stories based on the teams internal knowledge of the market and customer. Ensure that the User Story template is adhered to by just using “ The User” where ever it asks for who. When there is a requirement that is internal facing, use an internal stakeholder. e.g. “The Developers” for uprgading dependencies, or “The Product Owner” for internal reports and analytics.

Resulting Context

  • User Stories become a list of features and tasks that just need to be executed.
  • There isn't scope to discuss alternative solutions because their isn't a shared understanding of exactly who needs the solution.
  • The product ends up with too many features that aren't used or difficult to use

Alternate Solution

  • Build a clear picture of the different User and Stakeholder personas.
  • Focus on those Personas, the problems they have, and what solving those problems will do for them
  • Bring the team together to create shared understanding and discuss options to solve those problems

Discuss...

#UserStoryAntiPatterns

Problem

User stories are missing the context the team needs to have a good discussion.

Context

  • The team is new to Agile methods
  • The organisation is in the process of an Agile transformation.

Forces

  • Team members are unsure how to reframe their requirements as User Stories
  • There is pressure to succeed with the Agile transformation
  • Lots of literature about user stories proposes a template that user stories should follow.

Supposed Solution

Proscribe a format that every User Story should conform to. Ensure that every User Story conforms to that format.

Resulting Context

The team becomes overly focussed on ensuring the format is correctly filled in rather than ensuring that the User Story provides enough context for the team to be able to have a useful conversation about it.

“When you find a project team that is focused on producing a standard document rather than on considering the content of that document, then you are in the land of the template zombies…

In the land of the template zombies, form takes precedence. It is not necessary to think about the content of the document. It is not really necessary to think at all. The important thing is to have something—anything—under each of the prescribed headings. Not surprisingly, template zombies are adept in the art of cutting and pasting and ignoring anything that does not fit the dictates of the template.”

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior; DeMarco et. al

Alternate Solution

The team dicsuss and agree what context is important to them so that they can capture User Stories to discuss later. They may create or use a template that helps them to remember what they have agreed, but do not require it to be used. They document the template and its purpose.

Discuss...

#UserStoryAntiPatterns

Problem

Key milestones are being missed due to defects and rework.

Context

  • Engineering team say they can't improve their estimates because the stories are difficult to understand and incomplete.
  • Product Owners argue that engineering agreed the stories when they made the estimates.

Forces

  • The Go-To-Market team are making plans and sharing dates with customers based on development estimates
  • Delivery dates are consistently being delayed
  • Everyone is asking for more certainty about delivery dates

Supposed Solution

Product Owners spend more time writing more detail into the User Story so that when the Engineering team are ready to estimate they have everything they need.

Resulting Context

When the User Story is first accepted by the Engineering team everyone feels that it is well understood. As development progresses they start to uncover things that hadn't been considered. The Engineers make assumptions based on their understanding of the User Story. These assumptions lead to unexpected behaviour and defects. This leads to rework, and more missed deadlines.

Alternate Solution

Representatives of the whole team (e.g. devs, testers, Product Owner, design) get together and talk about the problem that needs to be solved. The person that has the most context about tells the User Story. The team build a shared understanding of the problem and their approach to solving it.

Discuss...

Part of #UserStoryAntiPatterns

Problem

There are large, loosely defined ideas that the team want to consider for development later.

Context

  • The team use fixed-length sprints or iterations

Forces

  • The team must define a 6-12 month delivery roadmap
  • The organisation has an annual budgeting cycle

Supposed Solution

The team introduces a backlog hierarchy with a category above User Stories. These items represent things that will be worked on in the future roadmap. They are estimated and tracked independently so the rest of the organisation can plan appropriately.

Resulting Context

  • The team wastes time and effort tracking and deciding what type of backlog item something is.
  • Time is spent doing detailed tracking of something that is deliberately vague and intended to be further understood later.
  • Estimates made for these large, uncertain ideas are necessarily unreliable but detailed plans get made on the basis of them by other functions, like marketing.

Alternate Solution

The team spends time to understand their users’, customers’, and stakeholders’ problems and motivations. They identify opportunities for their product to solve those problems and prioritise the opportunities based on the value they provide. Their roadmap reflects the prioritisation of those opportunities and the investment that they want to make to address that opportunity.

Discuss...

I’ve been planning the Slicing User Stories for Agile Teams course with @Matt. We’ve obviously been talking a lot about user stories, when they work well and … when they don’t.

I’ve started to record some of those less successful approaches as anti-patterns.

I plan to publish them with a #UserStoryAntiPatterns tag, and I’ll update this post with links to them as I do. I’d be grateful for feedback!

Discuss...

Last month, I was made redundant by SmartBear. I'd been there since they acquired Cucumber Limited, where I was co-founder, in 2019. It took me a little by surprise and the process felt fast, but I didn't feel worried about it. That surprised me. I had concerns for my team – 'reorganisations' always cause upheaval for those that stay, as well as those that don't. I wasn't concerned for myself because I've been in similar situations before and they've consistently resulted in opportunities. In fact, I think of them as some of the significant events that have led to where I am today.

I've been lucky to have experience of working at a variety of organisations and with lots of different people. Each time I've learned new skills, new ways of doing things, and new things about myself. They've all been a valuable part of shaping my career, they've all come to an end, and they've all been followed by something new.

In 2008 Lehman Brothers collapsed sparking the Global Financial Crisis. My employers’ goal was to make sure no-one lost their job and they asked us all if we would be willing to reduce work a 4-days week and take a 20% pay cut. Everyone agreed, and it was hard on everyone. I found it terrifying. I had just bought a house and had a 1-year old baby. But it gave me a push to start looking for a new job. Something that would really help me grow as a software developer.

At another company I worked for, the business hit cash flow issues and the whole team were to be made redundant when the business closed. My UX design colleague and friend, Spencer Turner and I, took a leap and founded Heavies. We focused on helping people kick-off their projects. We'd help our clients to do research and ideation, and help them build the initial prototypes or MVPs. It was an exciting time and we learned a lot together about running a business, product development, and working with clients.

Taking opportunities to spend time working in Open Source on Cucumber Ruby led to me working on the second edition of the Cucumber Book with Matt Wynne and Aslak Hellesøy, and eventually led to me joining Cucumber Limited as a co-founder. I learned lots about the financial management of a business, launching a product, marketing and selling services and products, and selling a business.

When we were acquired by SmartBear, I took the chance to develop my product management skills. I'd been heavily involved in shaping our SaaS product 'Jam' and I wanted to keep working with customers and users directly. In my three years at SmartBear I've worked with a wide range of people. I've had the chance to see acquisitions from both sides of the table. I've worked with cross-functional teams to develop and deliver new products. As a Director of Product, I had the chance to manage, coach, and mentor other product managers. I've led cross-functional teams of product managers, UX designers, developers, and marketers. I've had the opportunity to be involved in some key strategic projects.

I'm sad to be leaving the people at SmartBear. I had a great team and we were working on some interesting problems. But, I'm excited about the future. There's a new opportunity just around the corner.

If you're looking for someone to lead your product or software engineering team, or if you know of any opportunities that you think would be a good fit for me, I'd love to hear from you. I'm always excited to explore new possibilities and see how I can make a positive impact. So please don't hesitate to reach out to me via steve@took.es or LinkedIn. Thank you!

Discuss...

Example Mapping is a simple but powerful tool. It can frame the conversations that help your team to build a shared understanding about what you are trying to build. It was discovered and popularised by Matt Wynne.

If you haven’t heard of Example Mapping before, Matt’s post Introducing Example Mapping is a great place to start. Alternatively, if you prefer video you can watch Aslak’s Example Mapping webinar.

Both of those resources, and many others online and at conferences, are a great way to understand how Example Mapping works and why it’s useful.

But how do you get started with your first Example Mapping session for you team? Having helped several teams introduce Example Mapping into their practices I wanted to share my tips for getting started:

  1. Pick a story. It doesn’t really matter what it is, except if you have “technical stories” they might not work as well. But pick one. Don’t try to do too much.

  2. Give yourselves a time limit, and at the end have the team thumb vote on whether you think the story is ready. Twenty-five minutes is a good amount of time. If you get “no” at the end try to schedule another session once the questions and concerns have been answered

  3. Don’t invite everyone. It might give you too much conversation. The sweet spot for me is 3 to 5 people covering at least the development, test and product perspectives. You can always run a second session on another story so other people can give Example Mapping a try.

  4. Have someone take on a facilitation role. Their job is to look out for conversations that are sweating the details too much. If no one in the room can answer a question— add a pink question card. If the conversation is drifting out of scope — take note of a new story on a yellow card. Eventually the team will do this naturally, but having someone specifically watching for it can really help at first.

  5. Don’t use Gherkin for the examples. Try drawing simple pictures or a simple notation that works well for your stories. We want the session to focus on discovery, moving to a formal language too early can stifle the flow of ideas.

  6. Have the person who came to the meeting with the least understanding of the story write up the “minutes” of the meeting as Gherkin scenarios and share back to check understanding. Even better do it as a pair.

  7. Do a mini retro at the end and talk about what went well, what didn’t and adjust for next time.

  8. Blog about your experience — we all want to improve the practice so hearing about what worked and what didn’t helps everyone!

Have fun, and please do let us know how it went!

Discuss...