The Far Reach team spent over a year and a half becoming a scrummy organization, and we’ve learned a few lessons along the way. In this series, we’ll share what we’ve learned and give you a sneak-peek into a typical day at Far Reach. The previous post was about
stand-ups.
My First Impression
When I started at Far Reach as a user experience designer, I knew the basics of scrum—stand-ups, Post-it Notes, sprints, etc. I didn’t know, however, about the ceremonies or the processes the teams went through to plan for the sprints—including
scrum poker.
Scrum poker is defined by Wikipedia as “a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative
size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are
then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.”
The first time I was a part of scrum poker, I downloaded the app the team was using and had a reference sheet of what the numbers (turned out they were points) meant. At this point, I was still not 100% sure what we were doing, but trusted the process and figured I would just wing it.
So, the first user story came up and, in my mind, it was a story only a developer could estimate. I was confused as to why I would be expected to try to estimate the effort of a story I wouldn’t even work on. As a designer, I didn’t even know
where to begin.
By the time we were done assigning points to the stories, I was looking around the room wondering if I was the only one thinking, “Why don’t the developers just tell us how many hours it will take?” I left the meeting trying to understand
the value in everyone helping point all the stories.
The Benefits of Scrum Poker
After a few more meetings, I noticed that everyone was really close, if not the same, on their point estimates. It was clear that scrum poker was helping the team gauge the efforts of all the stories, not just the ones that they would be responsible for.
The benefit that stands out the most to me is being able to use this platform to ask questions and raise potential concerns. I realized just because a developer is responsible for the task doesn’t mean the PO or designer doesn’t have questions
or concerns that may have been overlooked.
It turns out that pointing a story involves a lot more than just guessing how long it will take to complete. Pointing stories effectively requires you to consider not just time but also the complexity and risk involved. It’s these two areas where
team members not directly responsible for executing on the story add value to the process. They may not know the effort to develop something, but they can potentially identify areas of complexity and risk. And this is critical to understanding the
whole picture.
Additionally, had we been pointing stories as individuals, team members would have missed the opportunity to learn and understand the efforts of the different roles within the team. Over time, this insight becomes more and more valuable.
What I Learned
Every meeting, I continue to learn about the tasks of the individual members of the team and what goes into their processes, which helps me contribute more. I also learned I should’ve asked my team about the benefits of scrum poker instead of just
winging it. Having that context early on would have helped me add value to the process sooner and more effectively.