Since you’re reading my blog, I’ll assume that you’re either a relative, or you’re already somewhat knowledgable about agile software development. So, let’s jump right in... (Sorry, Aunt Gina.)
Given my drothers, I prefer to mix and match terminology and practices from Scrum and Extreme Programming. Here’s what I like to do:
Roles & Responsibilities
A Product Owner is responsible for:
- Defining and/or collecting the set of features to be implemented in the product
- Maintaining a Product Backlog of User Stories ordered by Business Value
- Presenting user stories to the Team during Release Planning
- Selecting user stories to place on the Release Backlog
- Presenting user stories to the team in more detail during Iteration Planning
- Selecting user stories to place on the Iteration Backlog
- Accepting or rejecting user story implementations during Iteration Review
- Presenting implemented user stories to other stakeholders during Release Review
- Determining whether or not to deploy software during Release Review
- Answering questions from the Team throughout the process
The cross-functional Development Team (or Team) is responsible for:
- Estimating stories with T-shirt Sizes during Release Planning
- Estimating stories with Story Points during Iteration Planning
- Splitting large (epic) stories into smaller, more manageable stories
- Calculating their team velocity using Yesterday’s Weather
- Incremental Design and Test-First Programming of user stories
- Maintaining a backlog of Technical Debt
- Maintaining code and test quality with Refactoring
- Presenting implemented user stories to Product Owner during Iteration Review
- Assisting Product Owner with presentation of implemented user stories at Release Review
- Asking questions of the Product Owner throughout the process
A Coach (or Scrum Master) is responsible for:
- Identifying and resolving roadblocks hindering the Team, including, process, technical and managerial issues, and more.
The Whole Team, which includes the Product Owner, Development Team and Coach, is responsible for:
- Conducting Release and Iteration Planning meetings
- Conducting Iteration and Release Review meetings
- Conducting Iteration and Release Retrospectives
Planning, Review and Retrospectives
As I hinted above, planning is broke down into three levels:
- Product Planning
- Release Planning
- Iteration Planning
As I am not a product planner, I will not try to discuss how that process happens. Rather, I’ll focus on the active development process through Release and Iteration Planning.
First off, I like some to see symmetry between releases and iterations. The only difference is the scale at which the two types of planning occur. Specifically, I like both releases and iterations to include:
- Review, and
Here’s what I mean by each...
Each release and iteration should begin with a planning session designed to select some number of user stories from the parent backlog for inclusion in the current cycle of the process. For example, during Release Planning, user stories are selected from the Product Backlog for implementation in the next Release.
Each release and review should end with a review meeting wherein the Product Owner (and other stakeholders) is shown the running acceptance tests and asked to approve or reject them. If an item is approved, it becomes part of the next release. If it is rejected, it is placed into the backlog for the next iteration (or release, potentially). These meetings are also often the source of additional user stories for the backlog. For example, the Product Owner may accept a user story as it is, but desire that something about it change in the next iteration before accepting the feature in the release review.
At the end of each iteration and release, after the review meeting, the whole team should get together to discuss process improvement. Some teams do this without the Product Owner. I recommend including them, as their perspectives are valuable and it serves to reinforce the concept of the “Whole Team.”
Release and Iteration Duration and Structure
Release and Iteration lengths are highly dependent upon local circumstances. But, given the ability, I prefer to do Quarterly Releases and Weekly Iterations.
Quarterly Releases may seem like a long time. But, many businesses are incapable of absorbing change much faster than that. So, unless you’re at a web start-up or in a highly regulated industry, I say try to match your release schedule to an existing organizational heart beat, like quarterly financial reporting. (Though, perhaps you don’t want to try to release new code the same day, week, or month you release financials.)
As for the structure of a release, here’s what I like to see:
- Five development iterations
- One slack iteration
- Five development iterations
- One slack iteration
- One review, deployment and planning iteration
A development iteration is a normal iteration. The customer pick stories for the team to build, as described above. A slack iteration is just like a development iteration except that the work comes from the Technical Debt Backlog. No new stories are implemented during a slack iteration, though new tests may be added to shore up code coverage. And, the review, deployment and planning iteration is exactly that: review the release, deploy it, and plan the next release.
Short iterations allow for rapid customer feedback. Longer iterations allow for more work to be accomplished. In my experience, Weekly Iterations provide the best balance between getting stuff done and running off into the weeds. Plus, it has the side benefit of guaranteeing you your weekends off!
I like to see the following structure to iterations:
- Planning happens first thing in the morning on the first day of the week.
- Review happens on the afternoon of the last day of the week
- The rest of the time is devoted to implementing user stories
- Except for weekends, which are reserved for personal use
There's lots more to cover, but I'm out of time for now. I'll post more later...