Backlog Architecture: Unifying Design and Development in a Backlog at Scale
Director of Program Management
projekt202
The legacy approach to designing software in isolation from software development engineers should, if not already, be history.
Demand for a simple and impressive user experience is the differentiator for many products, agnostic of industry or user base. Product owners need to adapt to a more modern approach to defining and prioritizing requirements. They must practice pragmatism when building and evolving software, even more so than before. They must evolve and consider a new dimension — observed reality. Including empathy into a product’s experience is only possible by qualitative observation. This kind of data is best accompanied with quantitative metrics from methods such as A/B testing, as one example.
With these new data points to consider, justifying business value is more complex than ever before. What has been found is that product owners need help to narrow the cone of uncertainty in determining feature ROI, which drives backlog priority.
These challenges cause us to plan and approach our backlogs differently. There is a need to increase transparency. Visibility is needed for individual craft velocity for specialized skills. The need exists to take as much risk out of estimating and release planning, yet being pragmatic when adding complexity to the backlog. Why? Because building software is expensive and failing to deliver is even more expensive. The traditional agency design-first and develop-later method is a massive risk to a company’s bottom line.
Products can’t wait to go to market. Seriously.
MVP is a not just a silly acronym for small, lean startup businesses; it’s one that is applicable to large-scale enterprises. In most cases, a product cannot afford to omit feedback from real users as soon as possible. Yes, there are extenuating circumstances where exposing an application too early could be detrimental due to market competition, but generally, this rule applies. Businesses need to see value and ROI quickly in their strategic initiatives. Releasing an MVP allows companies to benchmark progress and adjust to business demand quickly. This is why, at projekt202, we employ methods of concurrently gathering rich user insights by employing behavioral science-based observation practices to expedite the feature priority problems we need to solve for.
To minimize the variability caused by design and development dependencies in an experience-driven software roadmap, overlapping depend-on work streams are required. It’s no easy feat to have depending work streams operating together within a domain or product. At projekt202, we are often forming new teams and structuring work cadences with new clients that need products completed quickly and correctly to solve major business problems. This calls for an integrated and efficient Program organizational structure, Project Management activities, Product Ownership and backlog grooming ceremonies.
For example, our process for experience-driven software development begins with our Experience Strategy and Insights (ESI) team, accompanied with a seasoned User Experience designer typically with visual and information architecture skills. During this phase, our priority is gaining empathy for a target user base so that we can carry insights gained throughout the software design and development.
During field studies, the designer accompanying our ESI team is able to gain a foundation for the product’s experience needs and feature demands through the lens of the user. Acquired knowledge through this phase is paramount in designing and developing the right features and information architecture in order to create an enjoyable user experience.
After this phase, we begin prototyping the design. This requires the formation of a backlog. At this point, the fidelity of our backlog is typically at the feature level. Big picture epics need to be decomposed into consumable features that can be iterated on with product owners and SMEs through exploratory design and validation studies. A weekly cadence is best for this type of design iterations so feedback can be quickly acted on. This isn’t a hard and fast rule, but one projekt202 has found successful.
Features tackled with design requirements are branched into a user story with complexity estimates, idealistic tasks and acceptance criteria for the design deliverables. At the same point, we prep for development by also creating a dependent user story or stories under that same feature for the development deliverables. This is where backlog complexity can be arduous and needs a specific focus on maintaining quality consumables.
Design teams operating ahead of development
With experience-driven software design and development, the experience is key to accomplishing user adoption; thus, development requirements are seeded by design output and design user story deliverables.
Because of this, we recommend a design sprint cadence that operates two to four weeks ahead, but no more, in front of your development cadence. This way, the output from the design team — hopefully, a high-fidelity mock-up with annotations — is fed into the development-specific user story, aiding in the elaboration of requirements.
In the case of an existing Design System or even pattern library, wireframes at a minimum should be attached to development user stories and groomed further for technical dependencies. We have found this leads to much better estimation from our development teams because, as the old saying goes, “a picture is worth a thousand words.”
Why isn’t design just another task in a single story?
We have experimented with creating tasks for design, intermingled with development tasks on a single user story. There are complications with doing this. Experience design work also needs to be tasked down to the number of hours. All too often, these tasks require time for ideation and are more wrong than right, regularly not improving over time.
Another way to put it, creativity is a bit hard to task and estimate, so why force something unnatural? Applying a timebox has proven most useful for ideation activities to provide guiderails ensuring progress at intervals during sprint.
In most cases, your development team will be larger than your design team. If the development team is dependent on design output on a task and approval before they receive the final details on the pattern, the experience needs to incorporate your development team will become blocked Day 1 of a sprint. This also goes against scrum’s fundamental recommendation of only estimating and accepting user stories that are groomed well enough to estimate as accurately as possible.
Through user groups, colleagues, meetups and inquiry with other companies with integrated design and development pods or teams, some of them include design and development tasks on a single story, their approach is to leave the in-progress story open across multiple sprints until the story meets the development definition of done. Fundamentally, this is bad practice and it leads to an unmanageable, highly-inaccurate release timeline, challenging the very nature of MVP and go-to-market timing. It also breaks the impetus of scrum’s ethos, creating a potentially shippable product each iteration.
Benefits of craft-level user story autonomy
By separating design and development user stories, design and development crafts are able to join unified sprint-planning meetings and estimate based on relative complexity through each craft’s own perspective. This enables teams to estimate relative complexity for entirely different crafts on a unified feature, allowing a design and development velocity to emerge over as few as three sprints. In today’s agile teams, specialized skill sets do exist; it’s reality. If not carefully mapped to capacity, ideal hours and dependencies do bottleneck and will occur, stalling progress toward business objectives. Separating apples from oranges in terms of design and development velocity and complexity estimates is an effective way projeket202 has found to forecast MVP and release timing in general for our clients.
With a focus on user experience and incorporating empathy in a product or application, an empathetic design is an enormous benefit to the adoption of products. Being able to set realistic expectations for release planning using measured velocity metrics for all major inputs into release planning and road mapping is the key to happy clients and successful experience-driven software development initiatives.
