Quantifying the Uncertainty: Implementing Story Points on Design Project
Working on a design project that heavily involves qualitative data can sometimes make things uncertain. From translating findings to dividing the workload among designers, it can be hard to define the complexity of tasks in the same way as in engineering projects. This uncertainty sometimes prompts me to wonder.
“Can we have clear measurements for each task we work on?”
We were given the challenge to redesign the Ministry Of Education, Culture, Research, and Technology (Kemdikbudristek) website, including restructuring the information and creating wireframes in three weeks!
Faced with at least 2,000 subdomains from nine different departments with different target users, it is not surprising that complexity became the project’s major challenge. While a large number of subdomains may seem daunting, the finite nature of the task helps alleviate some of my anxiety.
From my experience, when faced with tight deadlines it can be easy to become too focused on tasks and overlook other vital details. This means focusing time and energy on the wrong things.
So how do we define the complexity of each task for better workload sharing?
Here, we borrow tools from our beloved Product Managers and engineers. The tools, called “Story Points,” in any software engineering project story points would help them estimate how much effort they need to finish a certain task.
Each story point will be estimated based on the risk of those tasks (given the impact and priorities), their complexity, and familiarity (reusability of components).
With Story Points, our PMs and Engineers can be more strategic in their work by having a clear visualization of the effort required for a specific task. This allows them to plan their sprints and distribute their workload more efficiently.
Implementing Story Points Into Our Project
We use these tools during our wireframing phase when we still have a finite foundation in the form of our Information Architecture. Different from research and insights, while translating IA into wireframes, we can see what information needs to be designed.
We then sort and group that information into specific modules based on its purpose, potential for higher reusability of components, and uniqueness. That lead us to 21 modules that need to be designed.
We then continued to discuss the story points for each module using a 1 to 5 scale. More or less this matrix shows how we assign each task to certain story points. As you can see here we don’t include the priorities on our matrix, why?
I think it's the nature of our work since we don’t have the leisure to push the task into the next sprint like another in-house team. So whether the deadline comes it's done. No more extra time.
For example, we gave our previous content module 4 points because it has: 1) high reusability since it contains some of the other pages like (news, announcement, publication, and gallery); 2) complexity isn’t that much since the purpose of each page is pretty straight forward; 3) medium effort, as we only need to adjust the filter content to finish this module. Still high on point since its component could be reused by other pages.
Even though we have a system to calculate the effort that we need, all of these points will still be based on our estimations and discussions. Therefore, there is no right or wrong. Instead of focusing on the points, make sure you have an open and safe space for discussions. This will benefit you the most.
Then we arranged these points with our timeline, defining how many points we need to complete each day, and ensuring that we won’t encounter any blockers during our work time.
eg. the content module that contains news, announcements, publications, and galleries will be built using some of our key components, such as filters and card content. These components will also be used by specific modules, such as service and department information. That’s why we are starting with the content module first.
Using story points forces us to oversee how we usually split the workload among designers differently, Why?
First, the required effort becomes more visible. This one helps us to arrange our priorities independently.
Having a clear target for each day helps us to be strategic with our timeline. It helps us understand our capabilities and acts as a stop sign, so we wouldn’t get lost in a long night of work.
Second, is the approach of module-based tasks, instead of pages. With module-based tasks, we work on a set group of pages that have certain characteristics. This approach makes it easier for us to identify which components have a high level of reusability since we are working with several pages instead of just one.
Thus, besides completing the page design, sticker sheet, or component list made in this project, can always be regularly updated. This will also help the process of working on other tasks since we always have readily updated components.
Learnings and Conclusions
Pretty simple, right? But after more reading, exploring, and reflecting, I realized that some aspects need improvement to effectively and maximize the use of these tools in our workflow. Some improvements that could be made in the future include:
#1 Using the Fibonacci scale instead of the 1–5 points scale.
The 1–5 scale can be confusing, as the small difference between the scales makes it difficult for the team to distinguish the value of the effort given. The Fibonacci scale could provide us with a more distinctive progression, so we can see the difference in the required effort for each task.
#2 Poker Round Planning
Silly me, we do our planning sessions verbally, which can lead to bias when assigning story points to a task. This might happen because we already know others’ preferences before stating our own.
To eliminate these biases, first, we could do the planning individually, then discuss by revealing our assigned points. This would allow the sessions to be conducted more objectively.
#3 Being More Meticulous While Defining a Module
Last time, I think we only focused only on breaking down the IA, so we ended up skipping the detailing process (I thought it was enough😅). This resulted in some tasks being given inappropriate story points, either too little or too much.
In the future, we can detail them again and ask for a second opinion on the task breakdown and the points given to be more accurate in determining points and workload distribution. This is important since we only have one chance to do all of the work. Can’t afford to add more time to work.
Despite our lack of experience from these little experiments, we learned a lot. From this exercise, we managed to define clear daily targets and make our day of work more productive.
One of the advantages we noticed from using these tools was the ease of identifying which tasks had higher reusability. Allowing us to work more efficiently and reduce overtime work.
So that’s it, I hope you enjoy reading. My comment section and DM are always open for discussion. See you for other thoughts of mine. Thank you.
Gilang is an aspiring designer with two years of experience in the field. Currently, he works at Somia CX, a consultancy that focuses on Customer Experience projects. Based on Malang, Indonesia. He would like to have a chat or any discussion with you. If you want to connect on linked in please do so, or if you are more comfortable with less formal channels find him on Twitter or Instagram.
