Pointers

Story Points voting for remote SCRUM teams

Duration: 2 months (2020)

Team: Si Le (Developer)

My role: end-to-end design

TL;DR

Si and I built a tool for his team to estimate Story Points more accurately. This experience taught me how to work effectively with development and shipped a lean product.

Pointers is a functional product — Try with your team

Host a room

Create a place for your team to join.

Cast Estimate

While voting, estimates remain private.

Stay in control

Track and manage voting progress in real-time.

When COVID-19 forced companies to work remotely, it left many teams struggling to find appropriate tools for niche activities.

Si’s team used Slack’s poll feature to estimate Story Points, which was far from ideal, so we partnered up to make this right.

Finding the root cause

Initially, I assumed that Story Points tools either didn’t exist or were too niche. While researching the market, I interviewed Si and observed how his team ran sprints.

1) Chaos from the get-go

Product Manager shared screen, switching tabs between JIRA and Slack to create polls for Story Points. Difficult to follow what’s going on.

2) Setting up for failure

Participants got zoned out, spending most of the time scrolling up/down on the thread, and voted on the most popular option anyway. Discussions went unproductive, leading to inaccurate expectations being set.

3) Reactive instead of proactive

In the next few days, people started to get upset at delivery speed as the Product Manager scrambled to edit the sprint roadmap and host another session.

Figuring out what to build

Creating simple user archetypes helped me define key feature requirements. This allowed Si to begin work on the backend while I prototype the concept.

  1. Create room & set up participant identity

  2. Session control with real-time visibility

  3. Voting parameters and input visibility

  4. Import task description, export vote results

Early feedback from Si and his team validated the functionality of the core flows. However, this would also take longer to build than initially planned, something we didn’t have an appetite for.

Pointers@2x (7).png

I focused on reducing input and cognitive load for the next iteration. We also made a prioritization matrix to decide which minimum viable features to build.

Design changes fit all tasks on one page and reduced the input count required to complete each voting cycle—40% for facilitator and 50% for participants.

We also decided to backlog the sizing method, timer, and import/export features as it would need another month to build. We were happy with this direction.

Building it

Having a good idea of how the MVP will function, Si began full development work while I designed the final product.

I used quirky copy and visuals (illustrations from Icons8) to add a playful tone for subtle moments of delight to an otherwise repetitive process.

We held regular check-ins. This helped us stay aligned and flexible, providing support whenever needed, and ensuring development meets design specs.

Outcome

Pointers was done after 2 months. As Si used it with his team in the next sprint, we also received positive feedback.

“I liked how I can just share the user story on screen and manage the voting session on my phone or my other monitor without switching back and forth.”

“Not being able to see others’ results while voting makes me think more intentionally about my estimation, so I think that was helpful. The cat puns are cute too.”

Improvements were called out, like a timer feature, or removing the excess input required for the facilitator to end the session—but nothing detrimental to usability.

Initially, we wanted to make Pointers for other teams to use. However, we found the market too niche to go that extra mile, so we kept Pointer as-is.

Ultimately, we were still thoroughly happy to achieve our goal. I gained invaluable experience, and Si’s team kept using Pointers to the day he left.