Chris here again, ILAO's ScrumMaster for the website rebuild. With 10 Sprints behind us, we're becoming more and more adept at the Scrum process. Today, I'd like to share a timeline of a typical Sprint and highlight a few of the lessons we've learned along our epic Scrum journey. I also plan to include a few tips that I hope will be helpful to other new ScrumMasters.
I. Week 1, Day 1 (1st Tuesday) - Starting a new Sprint
Early on, we decided that we’d stick to two week Sprints. Each Sprint starts with the Sprint Planning Meeting, where the Dev Team negotiates with Product Owner to decide which Product Backlog Items (User Stories) they will attempt to convert into a working product during the sprint. We initially thought that it made sense to start a new Sprint on Monday to coincide with the beginning of a new work week, but we have since have seen the error of our ways (discussed in IV below), so now our Sprint starts on Tuesday of Week 1.
At the Sprint Planning meeting, the Product Owner is responsible for declaring which items are the most important to the organization. The team is responsible for selecting the amount of work they feel they can implement within the sprint. One of the first hurdles that we face during the Sprint is getting through the planning meeting on time while still completing our goals for the meeting. We often found that we got off-track during this meeting and exceeded the scheduled time. This was in large part due to absence of a Dev Team Working Agreement, so during our last Sprint we sat down and had a rather fun and productive meeting to come up with ground rules we could all adhere to (see Dennis Rios’s excellent post from last week!). I would encourage other new ScrumMasters to urge their Dev Team to develop a working agreement as early as possible, it has been a great help.
After the Sprint Planning Meeting, the new Sprint is opened up in JIRA and everyone receives their assigned User Stories. After our first few Sprints, we found that our velocity charts sometimes didn’t look right. I learned that when starting a new Sprint in JIRA, you should first assign story points to each Product Backlog Item to be included in the Sprint, then add them to the Sprint, then start the Sprint - precisely in that order. This produces velocity charts that look the way you would expect.
II. Week 1, Day 2 (1st Wednesday) through Week 2, Day 1 (2nd Tuesday) - Working on Assigned User Stories
During the first five or six business days of the Sprint, the Dev Team works on their assigned User Stories. Every morning we have our Daily Scrum Meeting, which lasts for about 15 minutes. To address any hesitation to participate, as the ScrumMaster, I usually call on someone to go first then go around the room in clockwise order.
Members of the Dev Team are responsible for keeping track of their work in JIRA. We found that it was becoming difficult to figure out the status of a User Story in JIRA using the default “swimlane” columns of “To Do,” “In Progress,” and “Done,” so we added five new columns: (1) Built, (2) Ready for QA, (3) Testing in Progress, (4) Testing Completed, and (5) Testing Documented.
- “Built” means the User Story has been built in Drupal and the developer thinks it meets the acceptance criteria.
- “Ready for QA” means that the User Story has been built and testing scenarios have been created. The team member who drafts the testing scenarios moves the User Story from “Built” to “Ready for QA” when the testing scenarios are finished. (“QA” stands for quality assurance and includes bug fixes and user experience.)
- “Testing in Progress” means that one of the Dev Team members has started usability testing on the User Story.
- “Testing Completed” means that the User Story has been fully tested by a member of the Dev Team.
- “Documented” means that any documentation necessary to resolve usability issues has been created.
These new swimlanes have increased awareness across the Team as to where each User Story is in development. Duplication of effort is minimized and we no longer have to wait until our Daily Scrum meeting to know when a story is ready for testing.
III. Week 2, Day 2 (2nd Wednesday) through Week 2, Day 4 (2nd Friday) - Usability Testing and Bug Fixes
During the last few days of the Sprint, most of the User Stories have been built by the Drupal developers and the rest of the Dev Team begins to test the Stories for bugs and usability issues. This is often the most critical time during the Sprint, as stories can stand or fall on usability. To avoid duplication of effort, we added the new JIRA swimlanes discussed above and keep all of our testing documentation on Google Docs, so that Team members can see their colleagues’ work in real time. A notable change that we’ve made in the past few Sprints was to develop usability concerns into new Product Backlog Items that can become User Stories in later Sprints. This allows us to complete User Stories during the current Sprint and while still addressing usability issues later on in subsequent Sprints.
IV. Week 2, Day 5 (2nd Monday) - Sprint Review
On the last day of the Sprint, we have our Sprint Review meeting, where the Dev Team demonstrates a working product increment to the Product Owner. The Product Owner reviews commitments made at the Sprint Planning Meeting and declares which items she considers done. Any User Stories that the Product Owner does not consider done are added to the Product Backlog or carried over to the next Sprint.
When we first started using Scrum, we ended our Sprints on the last Friday of the two-week increment period, however, we have found it more beneficial to end at the end on a Monday instead, right before the Sprint Review meeting. This gives everyone time to wrap up any remaining work from the previous week and allows me, the ScrumMaster, time to get everyone’s Sprint hours into JIRA to calculate our velocity. Since it isn’t necessary that Sprints line up perfectly with the work week, we have found that ending the Sprint on a Monday gives a lot more breathing room than ending on a Friday.
We hold the Sprint Retrospective meeting on the following day, directly before the next Sprint Planning meeting. At the Sprint Retro meeting, the Dev Team reflects on their process, inspects their behavior, and takes action to adapt to future sprints. The ScrumMaster (that’s me) works with Dev Team to expose any organizational impediments. The Dev Team can also review and make changes to their Working Agreement at this time.
V. Final Thoughts
As you can see, we have learned quite a lot since we first started using Scrum nearly five months ago. We’re still learning as we go along, but we have made substantial changes to our procedures that have greatly improved our efficiency and team cohesiveness. Agile processes like Scrum have a huge advantage in that they can quickly evolve and adapt to the needs of the Team and the organization. We still have a lot to learn about Scrum, but little by little we have been adapting this process to our needs. With each completed Sprint, we learn a little more and bring this process closer to perfection.