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 reasons why we should implement Agile and what we hoped to gain from it. From those early goals came our roll out plan and we did a great job checking back to it for the first year or so.
During an early 2009 Focus Group meeting with key individuals from each role on our Agile/Scrum teams we realized how important it was to continually remind ourselves about the 12 Agile Principles. You see, we hadn’t kept them as visible and transparent as things such as our Sprint Board, our Mid-Range Planning Board and even our 6-12 month project goals. The 12 Agile Principles had been “forgotten”.
For those who haven’t seem them in awhile here they are for you review. Look for future blog posts (Fall 2010) touching on the importance and relevance of each of these Principles.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
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 are my thoughts from a post I made to the Scrum Alliance Google Group.
How complex are we really making this? It seems overcomplicated and takes away from some of the core reasons I find Scrum beneficial and useful.
As a Product Owner, I view the process as the following:
A) Request for a project is received
B) Initial “High-Level” User Stories are written
C) Team uses Poker Planning, t-shirt sizing (or for one of my teams animal sizing) to measure the relative size of the stories. We do this using a baseline story and ask, how complex, difficult, hard to know is this story compared to baseline story
D) I use the cost of the team (payroll, hardware, software, etc.) and the through-put (average velocity per Sprint) of the team to determine cost per point. This tells me estimated cost per sized story and therefore for the project
E) From experience (and in a post I made here most of you agreed), I multiply a buffer of 2-4 times the teams estimate and provide a cost range estimate for the project. The cost will be between $xxx,xxx (based on teams estimate) and $xxx,xxx (based on my multiplier).
If we move forward with the project then the user stories are broken down further and resized (1 high-level story might become 12 stories). If the cumulative cost of the 12 stories will impact your overall plan (timeline and cost), then be transparent immediately and share that information with your stakeholders.
Now to the question about how to handle story points when a story isn’t done by the end of the Sprint?
While it would be nice to hear and know what your best practice is regarding this question, how big of a deal is this really? As long as you are having a retrospective and you address and fix the issue of stories carrying from one sprint to the next, it won’t have that much of an impact on the average velocity and therefore doesn’t greatly impact the figures I use for planning. Just do what makes sense in your shop. If you don’t like it, talk about in your retro and hopefully you have enough freedom and self-managing permission that you can make the changes to fit your team and operation.
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 roles. While they take a decent stab their Product Owner description is off base. In a newsletter from Pragmaticsw.com they define the roles as the following:
- Product Owner – This is the person that identifies and prioritizes the features that will appear in a sprint. This is normally the CEO, CTO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product.
- Scrum Master – The Scrum Master is akin to the Proejct Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the sprint stays on course, no new features are added to the sprint, code inspection, and ensuring everyone plays by the rules.
- The Team – Each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation.
Given the Product Owner description above, how do you hire a Product Owner that is not a CEO, CTO or any other management level position?
One of the failures in the implementation of Agile is a Product Owner who is not 100% committed in time to the projects and the team. A Product Owner is part of the team in Agile and should be as available and engaged as the other team members. While this isn’t always possible, especially early in the implementation of Agile in your shop, this needs to be a goal and part of the implementation plan.
Roman Pichler writes on the Scrum Alliance website about the role that a Product Owner plays. The article talks about the importance of being engaged and in the drivers seat for the project at all times. This means a PO could have other responsibilities at a organization but their primary responsibility should be the team.
A Product Owner should have a deep understanding of software development, be well versed in Agile and have enough time to dedicate to the role and job as Product Owner. It is also good for the Product Owner to be versed in the business at hand and familiar with core business functions. The decision about hiring from inside or outside should be based on finding someone that fits the above criteria.
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 about not taking on a story in a Sprint until it is ready, not allowing changes to the story when in a Sprint and we define when a story should be considered done (complete). The absence of discussion about the process a Product Owner and in many cases a Business Analyst does to prepare a story is troubling. That process should be as clearly defined as the Sprint to Release cycle. Serge Beaumont does a good job touching on this as he talks about the Ready Board.
While the author, Serge, says that Agile has two stable ‘states’, I’ll refer to them two stable ‘history’ moments. A story being “Ready” and a story being “Done”. Those two moments in the history of the story are indeed the only times they are stable.
To illustrate here are three images from Serge’s blog:
The image above represents the two ‘history’ moments in the life cycle of a Agile story. Most of our focus in Agile is between the Ready state and the Done state. That is when a story is committed to by the team for a Sprint, worked on, tested, and delivered as Done. Remember that Agile encourages, even demands, a story be “Potentially Shippable” when it is “Done”.
The above illustration of where the PO focuses and where the Team focuses is a great one. Keep this one in mind as you look at the following illustration. This is where your focus as Product Owner (and in many cases a Business Analyst) should be. If you are fortunate to have a Business Analyst on your team, they would be focused along with you on getting “New” stories and moving them towards this “Ready” state.
The question of how to know if your stories are “Ready” or not is a good one. The key is to work with your development team(s) to help define “Ready”. They will help answer questions about; A) When is a story at level small enough for 1 iteration and B) When does it have just enough detail (along with Acceptance Criteria, etc) for the development team to feel comfortable starting their work? This conversation should be collaborative with the team and adjustable over time as the process is improved. As you work closely with your team(s) you’ll be able to set the standards for your User Stories and you’ll learn fairly quickly how to know your stories are “Ready”.
Before I had the “Ready” board concept in mind it was easier getting focused in on the details and spreading time to thin between new stories coming in all the way through to a story being done. It is easy to get lost given the below.
A Product Owners (and again in many cases a Business Analyst’s) responsibilities are varied and cover areas such as;
- Requirements gathering
- Developing user stories
- Communicating frequently with the business or client
- Analyzing importance and setting priority of user stories
- Being available to team in answering questions and providing clarification
- Planning for upcoming Sprints
- Planning for several future Sprints
- Negotiating with business or client and team
- Supporting team in their Sprint commitment
- Being familiar with technologies used by team
- Evaluating velocity and searching for new a better ways for team improve
- Being engaged and familiar with daily team issues
- Staying three steps ahead in all areas
One of the biggest challenges we face is staying far enough back that you see the forest instead of the trees when looking at the above list (there are 13 items summarized above). Stepping back far enough is critical to performing your core function as a Product Owner.
The Ready board is a perfect aide in ensuring you are able to stay far enough back from the detail of your project. In the life cycle of a story making its way from creation through to production and used by the end user, your Ready board is one of the best tools for you as a Product Owner.
Enjoy and please comment.
Thoughts and Posts
Working on my first blog post about Agile and being a Product Owner.