At the end of February, the development team met for a scheduled sprint review of Creo 1.0. You may recall from previous articles here (and here) that a sprint is a short development cycle, part of the agile process we use at PTC for Creo. The sprint review tells us internally exactly where we are with Creo 1.0 development and helps us decide where to go next.
And where are we? According to Scrum Master, Shawn Bellmore, we’ve already finished and tested a number of significant “stories.” I asked him to tell more:
GH: What’s the purpose of the sprint review?
Bellmore: The purpose of the sprint review is just that – to review what was done during the last 4-week sprint. It’s an informal meeting with a review of the projects that were selected during the sprint planning meeting, what was completed during the sprint, and a demonstration of the functionality that was completed.
GH: How does the typical review run?
Bellmore: The Scrum Master takes a few minutes to review and summarize the agreement between product owner and team. How many stories? What is the definition of done? How much effort did the team plan to invest?
Next the Scrum Master presents a summary of what the team actually accomplished. How many stories achieved the status DONE. Did the team invest more, less or the same effort as planned? If there were any important differences, the sprint review is the time to raise them.
GH: There’s probably 100s of stories for Creo 1.0, and we have really short sprints – how can you confirm that the overall project is on track
Bellmore: We use a release burn down chart. This is the primary tool for measuring progress and scope of the project. Scope, progress, and estimated completion date are all clearly presented in one easy-to-interpret chart. Everyone in the project sees the updated release burn down chart after each sprint.
GH: Does the continual testing help track progress?
Bellmore: Yes. The continual testing and monitoring of quality builds our confidence in the product. The number of unit tests and acceptance tests defined and passed should increase every sprint. Insufficient tests are early warnings, as are increasing tests fails. A rising number of open bugs may be a sign that the quality is not sufficient. The next retrospective would be a good time to discuss how to improve the situation and put activities in place.
GH: How does the team examine the functionality which has been delivered?
Bellmore: Typically, we have the QA team members demonstrate the functionality that was completed during the sprint. They will also bring up any quality issues or serious bugs that may need attention. Developers provide comments and feedback to the areas of code they were responsible for.
The product owner asks lots of questions and explores. This is a demo of the product users should be able to use, not a tour through the mine field. So everything they see should work.
Once they’ve seen everything, we can discuss briefly anything which was not successfully delivered. Why wasn’t it delivered? What needs to be different, so that it can be completed in a future sprint? Or do we need to rethink?
GH: So what are the specifics and highlights for February’s Sprint?
Bellmore: We’re pleased with the results of the February sprint. Take, for example, the direct modeling app for Creo. We’d listed 32 stories that would be implemented during the 4-week sprint, and we were able to complete 20 of them.
At the highest level, the most significant stories we completed and demoed included:
- Box Selection
- Line/Arc Tool
- Remove Surface
- Modify Round
- Glowing effect on selection
- Pre-highlighting on surface contours
GH: You didn’t implement all the stories. So what happens next?
Bellmore: Any stories that are not implemented during the sprint are returned to the backlog for reprioritization. Often, these are selected for the next sprint but sometimes the priorities change so the stories may be put lower in the backlog. The product owner examines the remaining backlog and determine how best to move forward. Since the release is timeboxed the only options they have are to reduce scope of the release by dropping the least valuable stories or increase the capacity by possibly adding other Scrum teams.
GH: So overall, is Creo 1.0 on track?
Bellmore: Looking at the overall release, I’d say we are on track. In some areas we are well ahead, like Schematics; in other areas we are a little behind, but have reprioritized the backlog and added capacity to the Scrum teams to get the most valuable pieces of functionality into the release.
Check back on the Creo blog for more details of Creo 1.0 from now until our planned release in June, 2011.
Image by Peter Hellberg