Product Management + Agile + UX: Part 1

• Greg Laugero
• View Original
• May 31st, 2013

Product Management has been greatly affected in recent years by the rise of both Agile development processes and User Experience (UX) Design. The fact that these two disciplines have had a rough time working well together has made it that much more difficult for the product manager, who is now on the frontlines of making them play well together. How you make this a holy alliance for any product management team is emerging, and it’s possible to outline some general guidelines, which I will do in this post and several follow ups. For background: I’ve recently worked through these in the last year working for a startup and talking with others about how they are making this work. Some of my effort was successful while other parts didn’t work so well. This post will focus on what I think are the three fundamental guidelines that make the alliance work:

1. Understanding UX roles within product management teams
2. Understanding how to structure Definition, Design and Development work using Agile
3. Understanding how to use “points” to accurately plan releases and to negotiate conflict

One quick note: I’m coming at this from a SaaS-based product perspective. I’m sure others will differ with me based on working on different types of digital products.

UX Is Part of Product Management

I’ve argued elsewhere that one of the great benefits of well-executed UX is to clarify requirements. When the requirements of a system are limited to BRDs or even user stories, there is a lot of room for error in the interpretation. Clickable prototypes provide a visual and interactive interpretation that leaves less room for error. These prototypes should be created by the UX team (more about how to do this in a later post). They can be used to validate the design and flesh out acceptance criteria. They should be handed off to development along with the user stories and acceptance criteria during sprint planning. The UX skills that I believe are core to most relevant to product management teams include:

• Information Architect: Responsible for organizing the navigational structure of the system, as well as any underlying semantic structure that supports analytics.
• Visual Design: A person who owns the look and feel of the product – colors, fonts, icons, buttons, etc. This should NOT be shared with Marketing. This person resides on the product team because he/she needs to understand the interactions of a complex application.
• UX Designer: A person who owns the interpretation of the stories into pages and interactions on each page (including mobility). Where the Visual Designer works with colors, fonts, etc., the UX Designer works in what we’d traditionally refer to as wireframes.
• UI Developer: A person who translates the work of the UX Designer and Visual Designer into HTML, CSS, and Javascript. This person should also have UX Design skills so that the he/she is not a bottleneck responsible for all conceivable interactions.

The number and need for these positions will vary based on the product, but for our SaaS product, this is what was required.

Definition - Design - Build

So, you might call this Agile-Fall, but there is a basic sequence that has to be followed: you have to define what you are building; you have to design it; you then have to build it; and then test it. You can do this as rapid iterations within sprints (Lean UX), but you’re still following this sequence. How you organize the sequence depends on the amount of work you have to do to bring a viable product to market. For us, we were building a sizable new product and entering a market where we had existing, mature competitors. In this case the MVP is much larger than what would be called for in a brand new market. Because the product was new and we had a lot of detail to work out in design, we organized our work into 3 types of “releases”: Definition, Design, Build. We called each a “release” because each team was releasing deliverables from one release to another. Each release spanned the same calendar timeframe and consisted of two two-week sprints. So, while development is working on release 1, the design team is working on release 2, and the definition team is working on release 3. Everyone working at once on release 1 wouldn’t have worked.

Definition

A Definition release delivers validated and ranked user stories to the design team and is driven by product managers. Three things happen in Definition: First, product managers turn the high-level desires expressed in the product roadmap into specific ranked stories that have enough detail for designers to go to work. We worked with a Product Advisory Board to do this validation. The PAB consisted of customers and other qualified people willing to work with us on defining the product. (More about PABs in another post.) Second, product managers make sure that all stakeholders know what stories have been prioritized for that release. Third, the development leads do an initial “pointing” so that product management understands how much is realistically doable when those stories go into the development release. While we ultimately tracked stories in Microsoft’s TFS tool, we used printed PowerPoint slides spread out on a conference room table to do the pointing and ranking. We would do this twice per Definition release with product management, development lead(s), account managers, sales, and the CTO in the room. This allowed all stakeholders to have a voice in how we were ranking stories. At the end of each Definition release, product managers would make sure that the stories were fully documented (including the initial points)and stack-ranked in TFS.

Design

The focus of the Design release is to deliver fully vetted, validated and stack-ranked user stories, acceptance criteria, and prototypes to development. On day one of the Design release, product management reviews these stories with the design team and collaboratively decides which require full blown prototypes, which require simple mockups (or other artifacts), and which require nothing at all. We also worked through which prototypes would require usability testing before handing off to development. Product managers work with the designers to schedule design work for each sprint. (Recall that releases break down into two two-week sprints.) Regular reviews would happen over the course of each sprint to make sure that all stories are being covered. We also conducted separate “readiness reviews” with development leads to ensure that our designs would fit their capacity and capabilities. At the end of the design sprint, product managers approve the prototypes (and other design artifacts) and new visual designs (which should be incorporated into the prototypes). The final thing that product managers do is to update the backlog and user stories with the major addition being the writing of acceptance criteria.

Development

Development release planning is a big show-and-tell day for product management and design. This is the 4 hour block where stories, acceptance criteria and prototypes are presented to the development team. Final pointing is confirmed (it should have been discussed all along in readiness reviews and other informal reviews) and sprint-level commitments are made. One note: I argued that the show-and-tell should be done by development leads. This got shot down pretty quickly. My argument was that development needs to understand the full context of the prototypes and user stories. Making them responsible for presentation to their colleagues forces them to “own” the stories and not just be order takers.

Dealing with Points

Effective pointing is critical to moving quickly through Definition-Design-Development. Done well, pointing becomes the foundation for product management to accurately lay out the product roadmap and negotiate competing interests across the organization. With respect to the product roadmap: Pointing is the basis for what stories will make it into a release only when product management builds up an understanding of what development can deliver with each sprint and each release. Therefore, development has to be diligent about tracking this metric, and product management has to be diligent about writing stories that are specific enough for development to evaluate and accurately point. You should track how story points evolve as a story moves from Definition to Design to Development. The key metric is how much change in pointing occurs from one release to the next. It should tend toward zero. My friend also implemented a process where individuals and/or groups could horse-trade points for each release. If development had a particularly large chunk of tech debt that they wanted to cover in this release, they could work with professional services to trade some of their points and get those back – presumably with interest – in a later release. This can work within teams as well. Ultimately, it’s up to product management to determine how to divide up buckets of points. This is where release “theming” comes into play, but more about that in a later post.

Up Next

In the next post on this topic, I’ll take up the challenge of UX productivity. Even by splitting out a Design release ahead of Development, UX still gets squeezed.