Discover more from Winning Strategy
User Story Complexity
How to determine the complexity of a User Story?
I’m Vibhor, and welcome to my weekly newsletter, the “Winning Strategy.” Each week I explore one question from you about agile, product, roles, processes, frameworks, career growth, working with humans and anything else that’s stressing you at your office. Send me your questions here, and in return, I’ll offer actionable, down-to-earth, and simple advice.
🔥 NEW in the newsletter 🔥
Starting with this one, the newsletter is now going to list REMOTE job opportunities available in North America (located near the end of the page).
Q: Thank you for the great Agile content on YouTube about US estimation. How can I help my team better estimate user story complexity, as our 3-point stories often end up being 8 points and vice versa?
Thanks for the question.
Mis-Estimation of story points is pretty common and can occur for several reasons. Below are some reasons why this might be happening.
Unclear effort required
Insufficient domain knowledge
Known but ignored risks
Inconsistent estimation techniques
Pressure from stakeholders to commit
The first 5 reasons collectively determine the complexity of a user story. Once you know how complex a user story is, you can easily compare and contrast the effort required for implementation.
For educational purposes, I have created a simple 5-step framework that you can use to calculate the Complexity Score of any (well-defined) user story.
The framework is summarized in the image below.
To effectively use the framework to calculate the Complexity Score:
The user stories must be written in a well-defined but concise form outlining the desired functionality and the value of that functionality to the end user. Ambiguous user stories make it difficult to assess the complexity.
Acceptance criteria for each user story must be outlined.
All team members must be available.
Team members should feel comfortable sharing their opinions, asking questions and discussing potential challenges.
In order to calculate the Complexity Score for each user story:
Gather your team members (preferably during the refinement session)
Present the user story and its acceptance criteria to the team.
For each factor highlighted below, reach a consensus on a rating from 1 to 5, with 1 being the lowest and 5 being the highest level of complexity.
Discuss with your team and assess a rough size of the user story in terms of the effort required.
Evaluate how well-understood the user story is. If the user story requires a lot of experimentation (spikes), its complexity increases.
Identify the user story's dependencies on other user stories, tasks or resources (user stories are supposed to be independent by design but may not always be possible). The more dependencies, the higher the complexity.
Consider the team’s familiarity with the technology and domain required for the user story. The complexity increases if the team has less experience with the necessary skills.
Identify potential risks associated with the user story, for example, technical resource challenges, security concerns, limited availability of the team, vacations, e.t.c.
Add the individual ratings for Size, Clarity, Dependencies, Experience, and Risks. This is the Complexity Score for that user story.
You can divide the Complexity Score by the maximum possible score (25) to get a complexity percentage. Use this percentage to categorize the user story into one of five complexity levels:
Very Low Complexity (CL1): 0-20%
Low Complexity (CL2): 21-40%
Medium Complexity (CL3): 41-60%
High Complexity (CL4): 61 -80%
Very High Complexity (CL5): 81 -100%
Let’s walk through an example user story:
"As a customer, I want to be able to reset my password via email so that I can access my account if I forget my password."
Size: Discuss with the team the effort and time required to complete this user story.
Consider tasks such as:
Designing the UI for the "Forgot Password" link and the password reset form
Implementing back-end logic for generating password reset tokens and handling token expiration
Integrating with an email service to send password reset emails
After discussion, let's assume the team agrees on giving it a 3 (on a scale of 1 to 5), considering the scope of the work.
Clarity: Evaluate the clarity of the user story's requirements and acceptance criteria. For our example, the user story is straightforward and has a clear goal.
The acceptance criteria could include:
The user can request a password reset from the login page
The system sends a password reset email with a secure link to the user's registered email address
The user can reset their password by following the link within a certain time frame (e.g., 24 hours)
The system verifies and updates the user's password securely
Let’s assume the team rates the clarity as 1 (the lowest level of complexity).
Dependencies: Identify any dependencies the user story might have on other tasks, resources, or external services.
In this case, the dependencies might include:
Integration with an email service provider to send password reset emails
Coordination with other user stories related to user authentication and account management, ensuring that the password reset feature aligns with the overall system design
Let’s assume the team rates the dependencies as 2 because, while there are some external dependencies (such as email service provider integration), the team has experience handling these dependencies and does not foresee significant challenges.
Experience: Assess the team's experience with the technology and domain required for the user story.
In this case, let’s assume the team has experience with:
Implementing password reset functionality in previous projects
Integrating with email service providers
Ensuring secure handling of password reset tokens and user data
Based on the team's experience and familiarity with the required skills, they might rate this one as 1 (low complexity).
Risks: Identify any risks associated with the user story, such as potential technical challenges, security concerns, or unknowns.
In this case, the risks might include:
Ensuring a secure password reset process, such as generating unique, time-limited tokens and securely updating user passwords
Handling potential email delivery issues, such as email bounces, spam filters, or delays
Ensuring the password reset feature complies with relevant data protection and privacy regulations
The team rates this one as 2 because, although there are some risks related to security and email delivery, the team has dealt with similar issues in the past and has mitigation strategies in place.
Calculating the total Complexity Score and level:
Add the individual ratings: S (3) + C (1) + D (2) + E (1) + R (2) = 9. This is the Complexity Score.
Divide the total score (9) by the maximum possible score (25) to get a complexity percentage: (9/25) * 100 = 36%. This is the Complexity Percentage.
Based on the complexity percentage (36%), this user story falls into the CL2 level category (34-66%). This is the Complexity Level.
How to prioritize user stories
To understand the process of prioritizing user stories in a product backlog, watch the video below (specifically the WSJF method)
To enhance the quality of the prioritization, calculate the WSJF score as follows:
WSJF = Cost of delay (CoD)/ (Complexity Score)
All you need to do is replace the Development Effort (as shown in the video) with Complexity Score.
How to estimate user stories
You can use the Complexity Level (CL1, CL2, CL3, CL4, CL5) to accurately compare the user stories to the baseline user story (watch the video below for user story estimation).
Select a user story with complexity level CL3 as a baseline.
Make sure you rate CL1 lower than CL2, lower than CL3, lower than CL4 lower than CL5 on the Fibonacci scale while estimating the user stories.
🙇🏻♀️ Further study
This post contains a great deal of information, so don't worry about attempting to remember it all.
Consider it more of a reference guide or a source of inspiration for when you're generating ideas. And when you do come up with brilliant ideas, hit me up!
I am always open to suggestions and feedback. Pls, let me know if I missed something or if something seems odd.
🌟Also, if you share parts of the post on social media, I request you to please use proper credits. I won’t be as frequent in sharing this kind of content if I have to track copies of it floating around on social media.🌟
🙋🏻♂️ Your Questions!
If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.
If you’re finding this newsletter valuable, consider sharing it with friends or subscribing if you aren’t already.
📌 Things I loved this Week
📚 Book - Empowered by Marty Cagan
These days I'm reading this amazing book called "Empowered," and I just had to share it with you! It's packed with valuable lessons from top tech leaders on building empowered product teams that truly thrive. Kind of like a detailed explanation of why “empowering” teams is super important.
📚 Podcast - Master your sleep and be more alert when awake
Fascinating listen. Convinced me of the importance of morning light exposure. I've begun enjoying my coffee on the balcony each day, and I believe it's already positively impacting my sleep quality.
🔥 Remote job openings
Questrade: Release Train Engineer (Toronto)
Questrade: Senior Scrum Master (Toronto)
Questrade: Senior Product Owner (Toronto)
Telus: Scrum Master (Vancouver)
EXL: Agile Delivery Lead (NY)
Metlife: AVP, Agile Marketing Lead (NY)
CBrands: Agile Domain Coach (US-Remote)
Have a fulfilling and productive week ahead 🙏
✍️ Quote of the Week
"The key to building great products is to empower your product teams, to provide them with the autonomy, mastery, and purpose they need to deliver truly extraordinary results."
“I share things I wish I knew in the starting years of my career in the corporate world"
Thanks for reading Winning Strategy!