Jira
monday.com
Estimating work is hard as it is. Using dates over story points as a deciding factor can add even more complications as they rarely account for the work you need to do outside of actual work, like emails, meetings, and additional research. Dates are also harder to measure in terms of velocity making it harder to estimate how much effort a body of work takes even if you have previous experiences.
Story points, on the other hand, can bring more certainty and simplify planning in the long run… If you know how to use them.
What are story points in Scrum?
Story Points are units of measurement that you use to define the complexity of a user story. In simpler words, you’ll be using a gradation of points from simple (smallest) to hardest (largest) to rank how long you think it would take to complete a certain body of work. Think of them as rough time estimates of tasks in an agile project. Agile teams typically assign story points based on three major factors:
- The complexity of work;
- The amount of work that needs to be done;
- And the uncertainty in how one could tackle a task. The less you know about how to complete something, the more time it will take to learn.
How to estimate a user story with story points?
Ok, let’s take a good look at the elephant in the room: there’s no one cut and dry way of estimating story points. The way we do it in our team is probably different from your estimation method. That’s why I will be talking about estimations on a more conceptual level making sure anyone who’s new to the subject matter can understand the process as a whole and then finetune it to their needs.
| T-shirt size | Story Point | Time to deliver work |
| XS | 1 | Minutes to 1-2 hours |
| S | 2 | Half a day |
| M | 3 | 1-2 days |
| L | 5 | Half a week |
| XL | 8 | Around 1 week |
| XXL | 13 | More than 1 week |
| XXXL | 21 | Full Sprint |
Story points of 1 and 2
Estimations that seem the simplest can sometimes be the trickiest. For example, if you’ve done something a lot of times and know that this one action shouldn’t take longer than 10-15 minutes, then you have a pretty clear one-pointer. That being said, the complexity of a task isn’t the only thing you need to consider.
Let’s take a look at fixing a typo on a WordPress-powered website as an example. All you need to do is log into the interface, find the right page, fix the typo and click publish. Sounds simple enough.
But what if you need to do this multiple times on multiple pages? The task is still simple, but it takes a significantly longer amount of time to complete. The same can be said about data entry and other seemingly trivial tasks that can take a while simply due to the number of actions you’ll need to perform and the screens you’ll need to load.
Story point estimation in complex user stories
While seemingly simple stories can be tricky, the much more complex ones are probably even trickier. Think about it: if your engineers estimate they’ll probably need half a week to a week to complete one story, there’s probably a lot they are still uncertain of in regards to implementation meaning a story like that could take much longer.
Then there’s the psychological factor where the team will probably go for the low hanging fruits first and use the first half of the week to knock down the one, two, and three-pointers. This raises the risk of the five and eight-pointers not being completed during the Sprint.
One thing you can do is ask yourself if the story really needs to be as complex as it is now? Perhaps it would be wiser to break it down?
You can find out the answer to whether you should break a story using the KISS principle. KISS stands for “Keep It Simple, Stupid” and makes you wonder if something needs to be as complex as it is. Applying KISS is pretty easy too – just ask a couple of simple questions like what is the value of this story and if the same value can be achieved in a more convenient way.
“Simplicity is the ultimate sophistication”
Leonardo Da Vinci
How to use story points in Atlassian’s Jira?
A nice trick I like is to give the team the ability to assign story points to Epics. Adding the story points field is nothing too in-depth or sophisticated as a project manager needs the ability to easily assign points when creating Epics.
The rule of thumb here is to indicate whether your development team is experienced and well-equipped to deliver the Epic or whether they would need additional resources and time to research. An example of a simpler epic could be the development of a landing page and a more complex one would be the integration of ChatGPT into a product. The T-shirt approach works like a charm here.
While Jira doesn’t have the functionality to add story points to Epics by default, you can easily add a checkbox custom field to do the trick. Please note that you’ll need admin permissions to add and configure custom fields in Jira.
Assigning story points to user stories is a bit trickier as – ideally – you’d like to take everyone’s experience and expertise into consideration. Why? A project manager can decide the complexity of an epic based on what the team has delivered earlier. Individual stories are more nuanced as engineers will usually have a more precise idea of how they’ll deliver this or that piece of functionality, which tools they’ll use and how long it’ll take.
In my experience, T-shirt sizes don’t fit here as well as the Fibonacci sequence. The given sequence exhibits a recurring pattern in which each number is obtained by adding the previous two numbers in the series. The sequence begins with 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, and 89, and this pattern continues indefinitely. This sequence, known as the Fibonacci sequence, is utilized as a scoring scale in Fibonacci agile estimation. It aids in estimating the effort required for agile development tasks.
This approach proves highly valuable as it simplifies the process by restricting the number of values in the sequence, eliminating the need for extensive deliberation on complexity nuances. This simplicity is significant because determining complexity based on a finite set of points is much easier. Ultimately, you have the option of selecting either 55 or 89, rather than having to consider the entire range between 55 and 89.
As for the collaboration aspect of estimating and assigning story points to user stories, there’s a handy tool called Planning Poker. This handy tool helps the team collaborate on assigning story points to their issues.
Here’s the trick: each team member anonymously assigns a value to an issue, keeping their choices incognito. Then, when the cards are revealed, it’s fascinating to see if the team has reached a consensus on the complexity of the task.
If different opinions emerge, it’s actually a great opportunity for engaging in discussions and sharing perspectives. The best part is, this tool seamlessly integrates with Jira, making it a breeze to incorporate into your existing process. It’s all about making teamwork smoother and more efficient!
How does the process of assigning story points work?
- Before the Sprint kicks off – during the Sprint planning session – the Scrum team engages in thorough discussions regarding the tasks at hand. All the stories are carefully reviewed, and story points are assigned to gauge their complexity.
- Once the team commits to a Sprint, we have a clear understanding of the stories we’ll be tackling and their respective point values, which indicate their significance.
- As the Sprint progresses, the team diligently works on burning down the stories that meet the Definition of Done by its conclusion. These completed stories are marked as finished.
- For any unfinished stories, they are returned to the backlog for further refinement and potential re-estimation. The team has the option to reconsider and bring these stories back into the current Sprint if deemed appropriate.
When this practice is consistently followed for each sprint, the team begins to understand their velocity—a measure of the number of story points they typically complete within a Sprint—over time. It becomes a valuable learning process that aids in product management, planning and forecasting future workloads.
What do you do with story points?
As briefly mentioned above – you burn them throughout the Sprint. You see, while story points are good practice for estimating the amount of work you put in a Sprint, Jira makes them better with Sprint Analytics showing you the amount of points you’ve actually burned through the Sprint and comparing it to the estimation. These metrics will help you improve your planning in the long run.
- Burndown chart: This report tracks the remaining story points in Jira and predicts the likelihood of completing the Sprint goal.
- Burnup chart: This report works as an opposite to the Burndown chart. It tracks the scope independently from the work done and helps agile teams understand the effects of scope change.
- Sprint report: This report analyses the work done during a Sprint. It is used to point out either overcommitment or scope creep in a Jira project.
- Velocity chart: This is a kind of bird’s eye view report that shows historic data of work completed from Sprint to Sprint. This chart is a nice tool for predicting how much work your team can reliably deliver based on previously burned Jira story points.
Add even more clarity to your stories with a checklist
With a Jira Checklist, you have the ability to create practical checklists and checklist templates. They come in handy when you want to ensure accountability and consistency. This application proves particularly valuable when it comes to crafting and enhancing your stories or other tasks and subtasks.
It allows you to incorporate explicit and visible checklists for the Definition of Done and Acceptance Criteria into your issues, giving you greater clarity and structure. It’s ultimately a useful tool for maintaining organization and streamlining your workflow with automation.
Standardization isn’t about the process. It’s about helping people follow it.
