As the year is rapidly coming to a close, you’re probably thinking about the upcoming holidays. Odds are you’re thinking about how you’re going to spend your Thanksgiving. Your travel plans, family plans, menus, and guest lists have all been sitting in a backlog in the back of your brain since last holiday season. It’s quite an undertaking – and follows a similar pattern to many corporate initiatives – especially ones that follow annual funding cycles.

GOOD OR BAD: YOUR HOLIDAY LOOKS A LOT LIKE YOUR SOFTWARE DEVELOPMENT LIFECYCLE

You might have made some mental notes about things you’d do differently, recipes you’d try, and queued up various requests received by friends and family. These mental notes are the same as customer feedback, product innovation, and regulatory pressures that a typical product team experiences – all sources of user stories that populate a product backlog.

Every year you deliver a Thanksgiving product. And every year, you attempt to make improvements to get the most joy (maximum value) out of your holiday – a big corporate mission for your family.

Last year when you recorded these stories to your backlog, they were messy and loosely formed – like almost every delivery cycle before it. The planning and grooming sessions that you’ve tried to be better about got pushed by competing priorities again. The next looming holiday (big company initiative) has also directly affected the quality of your backlog. You and your team are barely keeping up with the current release cycle for this product line. It doesn’t leave a lot of room for planning or leveraging lessons learned from the previous releases.

So, when you refocused your attention back to this holiday (product), you also returned to a backlog filled with half-baked user stories, notes, and fragments of ideas instead of well-described user stories and measurable acceptance criteria with clear guidance. What you thought would jog your memory or get the idea ready to execute left you wondering why the user story was there at all. For the sake of time, you started without well-defined acceptance criteria and backfilled as best you could – trying to stay just ahead of implementation. You went to the grocery store without knowing the full guest count or knowing all the ingredients needed, or even all the dishes you’d be serving.

This is ok. This is Agile. Though it doesn’t feel like ideal Agile – we’re not Martha Stewart after all – and we still deliver a good outcome. We can’t all have Martha Stewart perfection putting in stories. If we’re being real, we don’t have Martha Stewart time and resources – even if we have Martha Stewart vision and talent. Constraints are everywhere and we adjust as best we can. That means we’re going to start more often with less upfront. Unfortunately, our delivery team will take on the added burden and do more rework later in the process. The output isn’t going to be magazine spread ready, the number of side dishes less, and the wow factor not as shiny. We often feel like we’re not doing the process correctly. It can sometimes feel painful, but every cycle we keep aspiring to deliver in an ideal way.

DELIVERING A SATISFYING FEAST TAKES PROCESS MATURITY AND WILLINGNESS TO GROW

At Thanksgiving, a major source of positive outcomes comes from quality execution from the kitchen (development) – a kitchen that needs many cooks (delivery team) and a variety of dishes (user stories) to produce a satisfying value for the end-users and their expectations. Families with long standing traditions (mature Agile organizations) and a cultural understanding related to sharing the work (resource and project management) are enviable and tend to make quality execution seem easy and replicable by any team.

Just like every family who has hosted their first holiday, IT departments moving to a new delivery method (Agile adoption) experience a similar eye-opening experience. Adjusting to a new process that looks like another process you already do really is fundamentally different in practice. A few cycles into the approach, many teams are still finding their way.

While understanding the overall process (Scrum) and how to break down stories into workable pieces (feature decomposition) with clear expectations (acceptance criteria) sounds easy enough – it’s not. Moving towards smoother, lower-stress holidays requires a commitment to incremental growth that occurs over time and experience. To do so requires team communication, honest assessment, and most importantly, the ability, willingness, and resources to make those changes.

PEOPLE, PERSPECTIVE, AND DETAILS MAKE THE MEAL SUCCESSFUL

Communicating very specific scenarios for requirements or user requests can also be easily discounted – especially when they force implementation. When a planning session goes off-topic, it is those details that can make or break a delivery. Knowing whether a certain brand of store-bought cranberry sauce from a can is “an absolute must” or “will absolutely cause revolt” is important. If you’ve experienced this during a holiday, you know the repercussions can be huge. Document all the unusual comments, especially the tiny details and qualifiers – even if the reasoning isn’t completely understood.

Knowing the sources contributing to the user story in a backlog is just as important. We take for granted that the author of a user story is recorded in our requirements tools. The person asking for the requirement is often never recorded or is documented with unclear context. The suggester, department, area of the organization, user subgroup – any source of inspiration for the story also supports understanding the acceptance criteria. Every team has moments where prioritization decisions need to be made to deliver both minimally and optimally in a release. Having this information to look back on is a huge help in a multitude of ways.

NEW USER STORY CONTRIBUTORS MAY NOT BE TAKEN SERIOUSLY IN THE FACE OF LONG-STANDING PROCESSES

Little Allison was clear that next year we need 10 pumpkin pies and 8 cans of whip cream. She told you. You wrote down 10 pies and 8 whip cream. Coming from Allison, we might think that’s a lot of pies. We know there are 40 people at Allison’s Thanksgiving, but still it seems excessive. What we don’t know is that this host likes to send full pies with some of the college kids when he can. Ten pies is a metric. We can work with that. We think we know enough. We really don’t.

A recent, and now expected tradition for the kids is a game they like to play with whip cream that generates some big smiles and great moments (major business value). Just like the pies, not all the whip cream is intended for dessert that day. The numbers are correct, but they are not descriptive enough or sized appropriately to value outcomes, or even in the right product category.

Another team member could easily misinterpret the information. A team accustomed to delivering years of Thanksgivings at the same house could struggle to adopt new ways. And new sources may not understand what they want in terms of goal alignment. Having a composite, cross-categorized user story that may need to be decomposed later may later produce huge value with the smallest investment. Open-mindedness, flexibility, and new points of view to what is contained in user stories takes group effort and attention to all voices.

USER STORY CONTRIBUTOR PROVIDES REQUIREMENTS THAT NO ONE WANTS TO WORK ON

Your goals are to deliver the best meal possible with the least amount of stress and the highest amount of user satisfaction. Oh, but wait, there are more criteria we need to include. Aunt Janice has expectations. She’s your Regulatory Agency. If she’s not satisfied, no one is.

User stories need to account for more than user goals and expected actions. Your user stories and acceptance criteria should include the non-functional, non-revenue generating needs regardless of how much the team doesn’t want to deal with them or whether the organization is trying to avoid them and forget they ever existed. You aren’t able to get store-bought anything past Aunt Janice and you’ve got to include the regulatory needs and security expectations. Regulatory and compliance requirements fall into both functional and non-functional areas. Because they’re messy and loud and can be wholly unfun – they can get misplaced. These user stories have an enormous impact on your business.

IGNORING END-USER IMPLEMENTATION REQUESTS CAN SABOTAGE ROLLOUT

Cousin Paul expects that the stuffing is served directly from the turkey and that Great Grandma’s serving platter is used for the sliced ham. If it’s not, everyone will hear Uncle Paul’s opinions on the matter and so will the rest of Uncle Paul’s social network. There is value to considering who will be the first users who will react to what you’re serving. By including rollout-related acceptance criteria, especially for the user groups and influencers who can easily redirect the celebration and goodwill from your value proposition, you can give new feature sets the chance to take root and grow.

In best practice, requirements should be implementation neutral. No one tells the cook how to cook. An order is placed, a suggestion is made. This goes for how a meal is presented too. There are many product owners and users who expect a specific design. In Agile terms, especially during MVPs, the look of something shouldn’t matter – we should be designing to value outcomes, which should be design independent. Teams often discount the UX, marketing, and initial adoption aspects of delivery in pursuit of more functionality. The balanced inclusion of these factors in a release can determine whether your investment is a big success or sunk cost. Mature Agile organizations deliver not just the software development lifecycle, but the customer lifecycle.

GOOD MEALS CAN BE MADE BETTER BY ENGAGING LOCAL EXPERTS

As you sit down to enjoy your holiday, find your own versions of Cousin Paul, Aunt Janice, and Little Allison, find the parts of the meal that seem to be underserved or over prescribed, your implementation teams may be experiencing the similar types of struggles.

Learn new ways to address these challenges with Agile principles or how Agile experts can coach and implement concurrently. Find out more about how Trexin can help your organization to improve its approach towards Agile. We know how to breakdown complex ideas that bring the needs of everyone in the family (organization) to the same table.

Click here to connect with a Trexin Advisor and learn how we can assist you with your Agile Adoption & Readiness and how Trexin delivers Agile through delivery of its Technology Capabilities.