How I Personally Work with Product Teams

A Foundation of Two Separate Workflows

The foundation of this Product Lifecycle is that there are essentially two main workflows. The first workflow I like to call "Planning" and the other "Development." If you're working in JIRA, these can be two separate Kanban boards consisting of several different swim lanes.

The Planning Board

The goal of the planning board is simple - have completely fleshed out user stories that have been finalized by a PM, Designers, Devs, Stakeholders, and that have been groomed and estimated by the development team. By the time user stories leave the planning board, they have final designs attached to them, an accurate summary and acceptance critieria, and have been assigned an appropriate number of story points. Once a user story has made it through each swim lane of the planning board, it's final destination is the second board - The Development Board. This makes sprint planning a breeze as there are no surprises for anyone and each user story has story points assigned to them.

The 6 Swim Lanes of the Planning Board

1. UX to-do:
   This swim lane consists of all user stories that have either been created by the Designer or the PM. In everyday work life, often times feature requests, ideas, or requirements come to either the designer or the PM. This swim lane gives a place for them. It should be understood that not all user stories that go into this swim lane will be completed and released. User stories in this first swim lane will eventually undergo a process of evaluation and be vetted. Designers familiar with The 5 Stages of Human-centered Design Thinking should understand this swim lane to be the first two stages - Emapthize and Define. These serve as the appropriate steps to define and validate the problem, define potential solutions, and prepare for the next swim lane - "UX in Progress."

2. UX in Progress:
   Referring again to the 5 Stages of Human-centered Design Thinking, designers should understand this swim lane to be Ideate and Prototype. User stories at this stage undergo the main process of solution designing and prototyping.

3. Design Review:
   Once the designer has created several solutions and prototypes, a review session should happen. At minimum, this should be at least between the PM and the Designer, but may also include one or more developers. This gives everyone the opportunity to walk through the user story together and make sure they're all on the same page. If feedback requires additional design or revisions, the user story may need to go back to the UX in Progress swim lane. Otherwise, if everyone is aligned with the direction of the user story, it should move on to the next swim lane - "Stakeholder Review."

4. Stakeholder Review
   Both the PM and the Designer then meet with stakeholders to review designs and plans to move forward with developing the user story. Similar to the review a PM and Designer go through, if feedback from stakeholders requires additional revisions or changes in the approach to the user story, the user story may go back to Design in Progress. It's just much easier to approach this stage as a PM and a Designer if you're both on the same page and aligned in direction.

5. Testing
   Once the designer and PM have reviewed designs and prototypes with stakeholders, and before developers begin grooming and estimating the user story for development, the designer should test the proposed designs and prototypes with several target users. The reason this is done at this stage is because sometimes, as designers, we gain additional insights from users in the testing phase that we may have missed in the Empathize phase. If these insights warrant changes in the design or solution, the user story may need to move back to the UX in Progress swim lane.

6. Grooming
   Finally, once designs and prototypes have been tested and validated, it's time to groom and estimate the user story as a team. The benefit of following each of the previous 5 steps is that by the time developers are grooming and estimating the user story, it's been thought through, tested, validated, and is a much more concrete solution than just an idea. This also means there is much less likelihood of throw-away work by developers. Once the user story has been estimated and assigned an appropriate number of story points, the next destination for the user story becomes the To-Do swim lane of the Development Board.

The Development Board

One of the benefits of having the designing and estimating stages of the user story happen on a separate board, team members can be assured that the only stories developers are actually working on are those that have been appropriately vetted, approved, and estimated. I've seen too many product teams where developers are surprising both designers and Product Managers by developing something in a vaccum that no one expected. This doesn't mean developers don't have a say in what gets built as anyone on the team can create a user story for the first swim lane of the Planning Board. But when user stories are formed and progress in this manner, team members are less likely to work in a vacuum because everyone is much more involved in the process from the beginning. This development board is pretty typical too by the way and is totally expected to differ slightly based on the makeup of the team.

The Swim Lanes of a Development Board (Typically)

1. To-Do
   The To-Do swim lane of the development board is essentially all user stories that are ready for sprint planning. These finalized, vetted, and estimated user stories make sprint planning a breeze. A seasoned development team usually knows how many story points they can complete per sprint, so planning a sprint with a backlog of user stories like these is a piece of cake. Consequently, Product and Project managers can more easily respond to the ever common question -"So when will this be done?"

2. Dev in Progress
   Once user stories have been planned and the sprint is underway, and a developer is assigned to the user story, it is moved into the Dev in Progress swim lane and coding begins.

3. Code Review
   This swim lane is self explanatory. Many dev teams approach this phase of development in various ways. Ex. peer review, unit tests, etc.

4. Design Review
   At this stage in development, it's helpful to have a designer review the feature branch or a test build. If anything is out of spec with the designer or the acceptance criteria of the user story, a designer's quick feedback to the developer assigned to the user story can go a long way in saving time with bug tickets in the future.

5. QA
   This swim lane can be one or several swim lanes, but the general idea of this stage is that QA engineers test the branch and verify that all acceptance criteria has been successfully met.

6. Done (Release)
   When the user story has been successfully passed by QA it is approved for release.

A Word on 'Lean UX'

The general premise behind the steps I outline above is inspired in part by the book 'Lean UX' by Jeff Gothelf. Traditional UX design methods can be (not always are) documentation-heavy and often can fail to keep pace with the iterative, fast-moving cycles of Agile development. However, even the above process can be scaled even more "Lean" to adjust to various product team and project situations.

A word of caution: A product team, no matter how lean, should never have an absense of UX, Development, or Product Management. Sacrifices are often made and traditional methods may be altered, but leaning a product lifecycle out to the point where one of those three becomes completely absent is far more risky than the potential rewards.

In Conclusion

Bottom line, when product teams work closer together and in harmony, countless problems and throwaway work can be avoided. Again, I don't claim to be an expert in JIRA workflows or project management, but I've personally introduced this workflow into each of the product teams I've been a part of over the last few years and it has yielded great success. I think it scales really well to larger teams, results in better transparency, there's no question of who's working on what, what's ready for development, and little to no surprises for every member of the team.