For release planning of a new, multi-phased project, our team was looking for opportunities to further tune our Lean and Agile estimation processes. We always look forward to continuously improving our existing Agile practices, and one improvement we identified was a quicker turnaround time for completing the estimation exercise during release planning. We had used Planning Poker in an earlier, similar project, but we were looking for a tool that could help the team estimate efficiently and even more quickly.
Initially, our quest to put even less effort toward estimation made lot of our stakeholders, including few new team members, uncomfortable. We organized an estimation workshop to review a few best practices in Agile estimation and brainstorm some ideas. Thankfully, there are lot of good reference materials available here in Scrum Alliance blogs and elsewhere on the Internet to help build perspective. The key question from those who opposed this improvement was regarding the accuracy of such estimates. We had to ask ourselves what additional value business/sponsors would get even if we tried to perfect an estimate by putting in additional hours. An estimate is, by definition, an approximation. However much effort you put into this, it's still going to remain an approximation. At the end of the workshop, everyone accepted that for most scenarios we could complete estimations more quickly than we had been.
We tried to adopt a method that is inspired by an affinity-based estimation technique by Lowell Lindstrom. To put a context around the team's goal in this new project, we wanted to complete our estimation exercise for about 400 user stories in 2 to 3 hours. The same team had completed an estimation for about 200 user stories in 3 hours for a similar project using the Planning Poker technique.
To prepare for the estimation meeting, we did the following activities ahead of time:
Step 1: Select relative sizing technique to be used (5 minutes).
Groom the backlog: In our case, we had couple of backlog grooming sessions prior to the release planning meeting. Our product owner was ready with list of items in the form of a product backlog in an Excel spreadsheet. The team walked away with a good understanding of the user stories. Also, it gave a great platform to our PO to test-run the user stories and make adjustments as needed.
Decompose complex user stories: Although ground rules don't sit well with a constantly changing world, defining a few ground rules helped us coach our PO in breaking large, complex user stories into smaller chunks. Our objective was to define simple user stories with easy-to-understand, single business goals.
Collaborate early: We circulated the product backlog to all participants beforehand. We used collaboration tools (such as the discussions forum through Rally software) to facilitate discussions among team members or with product owners.
Print information: All user stories and their acceptance criteria were printed on index cards ahead of time.
Gather supplies: We ordered lot of sticky notes of various sizes, a flip board, multicolored markers, and blue tape.
Book ahead: Admin booked a conference room with large whiteboards/walls all across -- the video conference facility helped to make it more productive with our distributed teams.
Educate in advance: Since a few of our team members were new to relative sizing, we organized a workshop to discuss relative sizing beforehand. In our case, we did a fun exercise with affinity estimation.
Notify ahead of time: The calendar invite was sent out well in advance to ensure in-room participation from all local participants.
Ask the team members to decide on a relative sizing technique, like T-shirt sizes (XL, L, M, S, XS) or Fibonacci (1, 2, 3, 5, 8, 13), etc. This should be a quick step and should involve limited (if any) discussion. Most of our team members wanted to continue using the T-shirt sizing method we had used in a similar, recently concluded project.
Step 2: Start silent relative sizing (20-30 minutes).
Place the smallest (with "Smaller" written on it) sticky note on the far left side and the largest (with "Larger" written on it) sticky note on the far right side of the same wall or board. Also, have a dedicated area on an adjacent wall or board for all "parking lot" or questionable user stories. The goal of this exercise is to arrange the user stories horizontally in order of their relative size, without talking
. The team placed the largest stories under the "Larger" sticky and the smallest stories under the "Smaller" sticky. Once all the user stories were on wall, the team got a final shot at making adjustments to the ordering, again without talking
Before starting the exercise, we let the teams know about few simple guidelines, such as:
Step 3: Edit the wall (40-50 minutes).
Team members can take a subset of user story index cards from the product owner and place it on the wall, relative to another item's size when considering the relative complexity and effort involved.
Arrange all user stories on the wall from smaller to larger relative size. As much as possible, stack all user stories with a similar relative size in one vertical group. Move them horizontally toward the "Larger" sticky note when its size is greater than the size of stories in the previous vertical stack.
Team members can use parking lot area to park the user stories that cannot be sized with given information, and when this isn't clear even after discussion with the product owner.
Team members are not expected to have any side conversations. This is a silent relative sizing exercise, so please refrain from speaking to others. If more clarity is needed, a team member can ask the product owner questions; the PO should be at the back of the room to provide clarity.
In this step, team members got an opportunity to edit the relative sizing on the wall. This step involved discussions among team members, and between team members and the product owner. Team members were empowered to change any relative sizing based on new findings. Everyone was respectful to others' points of view while editing the wall. Before drastically changing any relative size, it's good to bring others into discussions. This exercise needed a lot of facilitation and support from the ScrumMaster(s). The goal was to edit the wall, taking into account newly discussed information as quickly as possible. Team members discussed a few architectural design alignment issues on complex user stories, but they were advised not
to design the solution there. Team members also reviewed the parking lot user stories and sized a few more based on clarity achieved during further discussions.
For big teams, we can complete this exercise in batches instead of allowing everyone to start editing the relative size at the same time.
Step 4: Establish buckets based on relative size (20-30 minutes).
The goal of this exercise was to place the relatively sized user stories in same-size buckets. We selected T-shirt sizes (XS, S, M, L, and XL) as our relative buckets. Five different size sticky notes were used. We put the smallest directly above the "Smaller" sticky note from Step 2. We increased the size of each sticky note, with the largest directly above the "Larger" sticky from Step 2. Each user storie went under one of the five buckets, organized vertically with a goal of dividing all user stories into the relative sizes XS, S, M, L, and XL. Once the user stories were stacked up vertically, we used blue tape to draw boundaries to visualize the distinct buckets. Any user story that fell on the taped boundary was bumped up to the next bucket size, unless it was XL already.
Step 5: Have the "product owner challenge" (20-30 minutes).
So far in the process, the product owner was supporting team members by providing more clarity around the user stories. In this step, the product owner got an opportunity to review the relative size of the user stories placed under any particular bucket. The product owner flagged notes where he needed more input from the team member to better understand the rationale behind a particular size. For ease of identification, he placed a red-colored label on the user stories that needed further discussion. The product owner then discussed those items with the team. If the product owner's queries were addressed, then the red tab was removed and the team moved on to the next red-labeled item. If team members decided that an item needed to be resized, then those user stories were collected in a separate holding area for resizing. Team members then updated the relative size of those items based on further discussion with the product owner. This step was completed once all of the challenged items had been discussed.
Step 6: Save the data electronically (15-20 minutes).
After the estimation exercise was over, the team uploaded the product backlog from Excel into Rally (an Agile project management tool). The team helped the product owner capture the relative sizes into the software. (We flagged those items that were still in the parking lot and needed further discussion.) It is important to capture the relative size electronically before taking the user stories off the wall.
This exercise helped us immensely in making our release planning exercise more productive. Everyone, including the product owner, appreciated the time saved. We also shared this exercise with other teams during enterprise lessons-learned sessions. Now we hope this can help others as it helped us.