Product designers in scrum teams — Part 2
The full rundown of bridging design sprint and development sprint
Recap
In the previous article, I’ve share briefly about what I do during a sprint. If you don’t remember the details, do check it out:
Design Sprint + Development Sprint = 💪
Design sprint and development sprint are mutually beneficial.
The result of design sprint defines what to develop. Development sprint brings feedbacks to design the product better.
Moreover, in reality, to maximize the efficiency, Product Designers are actually running 2 design sprints and 1 development sprint simultaneously.
Product Designers are
- looping the final round of design sprint to ship for the next development sprint;
- starting a new design sprint for features in the future;
- joining the current development sprint to create product increment.
Step by Step Guide
You might see this graph many times. The key to remember is, design sprint and development sprint have independent timeframes, as long as the design is ready before the development start.
⭐️ Update Product Backlog
Most people tell us that this is Product Owner’s job. But as Product Designers know the best about the users and the design, the contributions of the below 2 can not be underestimated:
- Backlog Priority: Product Owner priorities the stories based on different factors, including user experience. It’s Product Designers’ responsibility to share knowledge and give advises for Product Owner to have a justified priority.
- Acceptance Criteria: Product designers know the experience and interface ins and outs. By documenting the expected behavior and specification in acceptance criteria, team members can align the expectation of each story.
⭐️ Sprint Planning
It is a chance for team members to sit together and communicate. It usually goes by Product Owner elaborating the requirements of stories. Product designers can help team members to understand the UX and UI, since it is part of the requirement.
Sometimes, the team may raise better ideas for the same value. The team can take the opportunity to discuss and adjust before starting the sprint.
⭐️ Daily Scrum
Most of the time, it’s important for designers to join the daily scrum.
Team members can learn about the product value more comprehensively by sharing each other’s work. It is also quicker and easier to spot the misunderstandings if there is any.
And since design always goes further than development, by knowing what designers are working on, engineers can build a more sustainable system.
Just like any other team members, Product Designers should also share the design work that has been done, will do and impediments.
Tools: Jira
⭐️ Product Increment
Product increment is a team contribution, including Product Owner, engineers and designers. Designers share the same responsibility to make sure the increment is “done”.
Of course, with the skills of Product Designers, the contribution on testing and validating UX and UI is especially significant.
⭐️ Sprint Review
Sprint review is a great chance to hear feedbacks and updates from a different perspective.
During the sprint review, Product Designers can clarify for the design related questions raised by the audience.
In addition, sprint review is not a judgment day. It’s also a great chance to get different insights, which will help in the product design in the future. It can be customers feedbacks from the support team. It can marketing strategy by the sales team. It can also be security updates by SRE. There is definitely something worth learning.
⭐️ Sprint Retrospective
Product Designers, as part of the scrum team, should celebrate the success and learn from mistakes as well.
All team members, including Product Designers, should share what has done well, what to improve and action items. It doesn’t have to be related to design. It can be anything that can help the team grow.
Tools: Confluence
⭐️ Understand
This step helps Product Designers to define problems better, more specifically in scrum, to understand the priorities of problems as well.
The research process has no difference from what Product Designers usually do: who are the users, what are the pains and needs, what is the context, competitor review etc.
In scrum framework, however, there are more frequent releases and product increments. That means more material is available to enrich the result.
Tools: Mixpanel, Zendesk, Google Analytics
⭐️ Ideate and Decide
It’s time to get hands dirty. Draft as many solutions as possible, from low to high fidelity, from happy paths to edge cases.
Tools: Pencil&Paper, Sketch
⭐️ Prototype
Prototype tells how users are actually going to use it by simulating the actual product. It will be helpful for both deciding the ideas and validating it.
Depending on the project, prototype of different level of fidelity can be made. Starting with the simplest one will the more cost-effective.
⭐️ Validate
Feedbacks can evolve the design to another level. Borrowing other’s eyes can find the blind spots, why it works or why it doesn’t.
Make use of the prototype from the previous step and the actual market feedback to validate it internally and externally.
- Internal validation: validate it with the support team, sales team, development team, other product team, stakeholders etc. Each of the groups delivers feedbacks from a different perspective. Define what kind of feedback you would like to get to select the group.
- External validation: not only from the result of the previous release in the market, but also dummy demo of ideas to users and potential users.
Tools: Sketch, Marvel, Mixpanel, Zendesk, Google Analytics
There are definitely more problems rising as the team members work together. How are product designers work in your team? I would love to hear.
Recommend to read: tips about defining your own process:
