Do you hold frequent Design Review Meetings?
Trouble getting your development team on the same page with your User Stories? Difficulty figuring out how to get initial “rough” sizing on your backlog items so you can better prioritize or groom your backlog? Here is an approach to Design Review meetings you can customize, tweak and change to suit your shop and teams.
This example assumes you are an Agile or Scrum shop, have met with Stakeholders and are ready now to share with the team(s) and get sizing estimates. The example includes the steps used in preparing for the meeting and I hope it helps at least get the juices flowing for how this might help you in your process.
Overall purpose of the design review
Since we are an Agile and Scrum shop we have interviewed our stakeholders to gather initial requirements and written out User Stories to represent those requirements. Each User Story outlines the request from the stakeholder for a feature or requirement and also includes their acceptance criteria. The goal of this design review meeting is for us to present the overall vision of the project and read through each User Story. As a development team we need you to size each User Story in terms of relative complexity (one story is twice as complex as the previous one), we need you to think about system areas or components including if we have code in place to handle each User Story or if new code must be written, are the various systems connected already, is a database involved, and so on.
Structure of Design Review Meeting
This will be both a directed and informal meeting. The introduction and reading of the purpose and User Stories will be done by key stakeholders and me as Product Owner/Project Manager. We will then sit back and let the process unfold with the team, only giving time constraint updates. We are also there to help answer any clarifying questions from the team.
Participants in Meeting
Key Stakeholders
Product Owner/Project Manager
Scrum Master
Developers on team
Quality Assurance on team
Database developer on team
Business Analyst or Systems Analyst
When and where will this meeting take place?
With around 50 User Stories to review, we will conduct these meetings in three 2 hour sessions. They will take place in Conference Room Elephant starting at 10 AM on Monday, Wednesday and Friday.
What should I do to prepare?
We will ask each participant to read the project vision and the User Stories. These will be provided without the Acceptance Criteria and will serve as an introduction to the process and format of the meeting. They will be asked to come up with 4 or 5 examples of similar User Stories they have recently worked on to use as baselines for estimating complexity.
Questions I will be asking during or at the conclusion of the meetings?
1) What is the complexity size of the story?
2) Any changes to the UI, middle tier, or database?
3) Does this require a new Data Model?
4) Any services involved that aren’t already in place?
5) What is your comfort level (scale of 1-5) with information in User Story? Could you begin development work today?
6) Any particular User Story(s) stand out as needing to be done first from a development standpoint?
7) After hearing and discussing all the User Stories, are there any particular areas of concern (other than the obvious unknown factors)?
8) After hearing and discussing these User Stories, where do you feel the bulk of work and focus will take place?
9) Do you plan on using a Test Driven Development approach to this project?
10) How does Quality Assurance feel? How complex and what types of automation can be used?
——————————————————————————————————————————
I’d love to hear your feedback or thoughts on this approach to these meetings. As always, this is just an example of an approach that has been successful for me.
Hi Jack, looks like a good format. Have you thought about doing this using story mapping? I think maps are a great additional dimension to seeing the list of stories.
Also a question for you — do you find that there is any trouble between your developement team and stakeholders in ‘speaking the right language’? And do you provide translation if that is true?
Yes, User Story Mapping is something I am looking in to. Love the two dimensional view story mapping would provide. A little uncertain about how it would apply at my shop currently but I am very interested.
Language differences are always an issue and new stakeholders to the process are at times lost. Since we don’t always know which stakeholders are in the mix, I find following up with them and explaining Agile/Scrum and offering dialect descriptions is important.
Jeff Patton’s has a great article on this (http://bit.ly/1KQp). Some of the great things about it are how it keeps the context – that is, how stories relate. It also gives you and your stakeholders a sense for where the development efforts will focus and when.
We’ve been using them for a few months now and they seem to be a good communication device.
I like the questions to be asked during the meeting – great suggestion!
50 user stories at once sounds like a lot. We do about 15 at a time since our Product Owner only writes them up one sprint in advance so we have a session every two weeks (once a sprint).
Thank you for your feedback. What is interesting to see is how each IT shop/company is unique which just makes the discussions of how to use Agile and Scrum even more exciting.
For companies working on one or two projects (applications) at a time, the sizing and planning one sprint ahead makes sense. I would assume though that you do periodically look out further then just one sprint ahead? I hope so. In this situation holding a Design Review session on a frequent basis makes sense and so does the fact you are discussing less stories.
For companies working on multiple projects and multiple applications at a time, it is important have frequent Design Review meetings as part of the process. These could be scheduled adhoc or have a set time (every week or two) where new stories are brought in for discussion and review. Goal is to ensure the stories are ready for a sprint.