An app for story pointing.
Story Pointing App Design Process
What was the problem?
Engineering teams didn’t like using third party story pointing apps because they had connectivity issues and save issues. The few apps they did use, they had issues with freezing and everyone had to leave the session multiple times and open up a new session to finish their story pointing.
How was I involved?
Our company was going to host a hack-a-thon and the UX team was approached by an engineer that wanted to work on this problem. He wanted UX to be involved because he wanted to create a solution that wasn’t just going to solve their technical issues, but also be usable by technical, and non-technical people. I volunteered because I have a strong passion for agile and appreciate the complexity of a problem like this.
What did people think?
With the limited amount of time, we did a quick usability test on our app and had a few questions we asked. Questions regarding how someone would enter a story pointing session and see if they knew how to, or if someone knew how to vote and add story point amounts.
This was a gut check process that helped us refine what we developed. Research was qualitative and it helped direct us. It helped identify if we had major issues, or cosmetic. I conducted these sessions with 5 different users (3 developers and 2 project managers) to get a well-rounded sample of data.
The process.
After meeting the first time and talking about some of the bigger problems of using other third party apps to story point, I examined each of the 3 third party apps and studied them. I also talked to several project managers on how they use those same apps. I leaned on my husband quite a bit because he’s a seasoned project manager. I ideated, and sketched a lot to make sure my workflow would make sense when I started prototyping.
I sent out a survey that helped me understand the most used tools in the marketplace, who was using them, and what their biggest problems were. I analyzed this data and shared it with the engineering team. We used this data to prioritize our list of features.
We met once every week to review the design and review the list of priorities and changed them anytime someone was spending too much time on an item, or if we didn’t have the time to start one of the bigger items, we shifted and I removed that functionality from the prototype and workflow.
The team and presentation.
The day of presenting each project for the hack-a-thon, there were at least 15-20 projects presented. Ours was the only project that had consulted the UX team and it made a difference. We won 2nd place in the hack-a-thon.