Posts by Jack:
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.
Agile Principles – why do I care?
Are you an Agile shop? Have you just been exposed to terms such as Scrum, daily scrums, Sprint/Iteration planning, Demo’s, retrospectives and more? Did you know about the 12 Agile Principles? Back in 2006 we discussed the implementation plan at our shop and laid out the pros and cons of Agile. We wrote down the [...]
Story Points – do they really matter?
There is so much talk about planning in Scrum. The basic questions are around how you handle your sizing of user stories. Also related is the discussion about how to handle situations where a story is sized but doesn’t get done in a Sprint. Do you carry the points over, resize and so on. Here [...]
Role of a Product Owner? Hire from inside or outside?
As Agile software development as a methodology is becoming increasingly popular so are questions about how to fill the role’s on a Scrum or Agile team. Here are the typical roles on a team: 1) Product Owner 2) Scrum Master (Project Manager) 3) Developer 4) Quality Assurance Here is one source that attempts to describe [...]
The Product Owner Ready Board
A few months back I discovered a blog post discussing the use of a Ready Board. The author, Serge Beaumont, lays out a well described argument for the importance of a Ready Board. We do a great job in Agile focusing in on the function of the team. We write and learn in certification courses [...]
Thoughts and Posts
Working on my first blog post about Agile and being a Product Owner.