Starting off, I'm PM for a small inside dev team. Before 2023 we were using Time Estimate as our time tracking of choice, and that provided many benefits. Paired with Bitbucket, devs could easily log time as they worked, and I had clear insight (without having to bug devs at a micro level!) into individual ticket progress. Beginning 2023, we switched over to story pointing. I (think) fully understand the rationale behind story pointing, but either I'm missing the benefits as a project manager, or there are very few. A couple things off the top of my head that I don't feel I'm getting with story points: * As said above, other than what column a ticket is in, I cannot get a sense of progress (how much work has been done, how close/far work is from estimate, etc). Is there any way to approximate this using story points? * While we're pretty good at estimating, there's always that ticket either over or under estimate when delivered. Using time, it was clear how much over/under work was done to complete ticket, and we could create filters etc to list them out for team discussion. We're trying to approximate this using a custom field, but the dev now has another step to enter something in "Actual Story Point" and this feels a bit arbitrary since it's based on opinion/feeling and not *actual time spent*. Is there any way to approximate this using story points? To be 100% honest, I'm no fan of story points but am resolved to get the most out of them because the team (and director :D ) wanted to try them out. 2 out of 4 devs appreciate time tracking, 2 out of 4 devs feel anxious about time tracking. To be clear, we've never and have no plans to use time tracking as a way to evaluate dev performance; time was only used to track progress, help define scope/timeline, and refine estimating (among other things). Our next step is to get closer to calculating a reasonable velocity based on story pointing, we don't have enough sprints done yet to get our first average. 99% of my internet searches on this topic result in pages of "how to implement story point" posts, but that's only the beginning step. I'm looking for more "veteran" tips on how story points fit into the day-to-day management of a sprint and larger project. Any help toward this would be *greatly* appreciated! <3

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Story Point Day-to-Day Workflow Questions

David Childers

Starting off, I'm PM for a small inside dev team. Before 2023 we were using Time Estimate as our time tracking of choice, and that provided many benefits. Paired with Bitbucket, devs could easily log time as they worked, and I had clear insight (without having to bug devs at a micro level!) into individual ticket progress.

Beginning 2023, we switched over to story pointing. I (think) fully understand the rationale behind story pointing, but either I'm missing the benefits as a project manager, or there are very few.

A couple things off the top of my head that I don't feel I'm getting with story points:

As said above, other than what column a ticket is in, I cannot get a sense of progress (how much work has been done, how close/far work is from estimate, etc). Is there any way to approximate this using story points?
While we're pretty good at estimating, there's always that ticket either over or under estimate when delivered. Using time, it was clear how much over/under work was done to complete ticket, and we could create filters etc to list them out for team discussion. We're trying to approximate this using a custom field, but the dev now has another step to enter something in "Actual Story Point" and this feels a bit arbitrary since it's based on opinion/feeling and not *actual time spent*. Is there any way to approximate this using story points?

To be 100% honest, I'm no fan of story points but am resolved to get the most out of them because the team (and director ) wanted to try them out. 2 out of 4 devs appreciate time tracking, 2 out of 4 devs feel anxious about time tracking. To be clear, we've never and have no plans to use time tracking as a way to evaluate dev performance; time was only used to track progress, help define scope/timeline, and refine estimating (among other things).

Our next step is to get closer to calculating a reasonable velocity based on story pointing, we don't have enough sprints done yet to get our first average.

99% of my internet searches on this topic result in pages of "how to implement story point" posts, but that's only the beginning step. I'm looking for more "veteran" tips on how story points fit into the day-to-day management of a sprint and larger project.

Any help toward this would be *greatly* appreciated!

Accepted answers

Trudy P Claspill

Hello @David Childers

You might benefit from this article from Atlassian on Estimation and the role played by Story Points.

https://www.atlassian.com/agile/project-management/estimation

Story points are a way to gauge the amount of effort needed for a task. They do not necessarily correlate one-to-one with amounts of time. In my experience they are a way to says "this is a small (or medium or large) effort task" during the backlog grooming activity, and help you determine if you need to break bigger effort items into smaller items.

Story points are not a means of tracking progress on a work item. Burn downs using Story points are based on done/not-done; the points don't burn down until the item is in a "done" status.

In my experience, if progress needs to be tracked at a finer detail than high level to-do/in-progress/done, you either use Time Estimation exclusively, or you can use Story Points during backlog grooming as a gross estimation, and combine it with Time Estimations done at a later point to refine the effort estimate and use Time Tracking to monitor the progress against the estimate.

Dan -minware-

Disclaimer: marketplace partner!

Hey @David Childers - my recommendation would be to think of 1 story point as 1 day. Some people don't agree with this (edit: see!) but I don't really understand why - eventually the story point estimate is converted to time because the whole point of the exercise is to be able to identify tasks that took more time than expected - why not keep things 1:1?

Either way - what you're looking at when you compare how long you thought something would take to how long it actually took is called velocity and identifying low velocity tasks is exactly what you are setting out to do.

Our solution (minware) could potentially help - we automatically calculate velocity at the task level without any worklog or timekeeping required (super cool technology) and flag the Low Velocity tasks that took longer than expected.

Here I'm showing a task that we thought would take 3 days and it ended up taking closer to 7 and was flagged by our Low Velocity notification:

You can expand each ticket and drill all of the way down to the commit level and talk about the task / what took so long.

minware is a 3rd party and it is a paid service but provides a ton of value - this is just one of thousands of metrics we offer to help your teams improve estimation and velocity.

We offer a free trial if you want to check it out!

Nic Brough -Adaptavist-

Story points are not supposed to be used as time measures, they are a comparative measure of estimates. "Relative difficulty" is a phrase one of my colleagues used.

If you have a story that is 2 points, you can look at others and say "that's half the size of the 2-pointer, so put 1 point on it" or "that's about 10 times the size of the 2-pointer, so put 20 points on it"

When you're doing scrum, "actual story points" is an irrelevance, because Story points are not for tracking beyond working out what can go into a sprint and then a velocity. If your estimates are turning out wrong all the time, you discuss that in the sprint retrospective and work out how to improve them.

I would strongly recommend you go back to using time tracking if you're starting to say "1SP = 1 day" and want to record Actual vs Estimate.

Or carry on using story points for estimation and velocity, but estimate and log time as the way to record actual work done.

All comments

Trudy P Claspill

Hello @David Childers

You might benefit from this article from Atlassian on Estimation and the role played by Story Points.

https://www.atlassian.com/agile/project-management/estimation

Story points are not a means of tracking progress on a work item. Burn downs using Story points are based on done/not-done; the points don't burn down until the item is in a "done" status.

Dan -minware-

Disclaimer: marketplace partner!

Here I'm showing a task that we thought would take 3 days and it ended up taking closer to 7 and was flagged by our Low Velocity notification:

You can expand each ticket and drill all of the way down to the commit level and talk about the task / what took so long.

minware is a 3rd party and it is a paid service but provides a ton of value - this is just one of thousands of metrics we offer to help your teams improve estimation and velocity.

We offer a free trial if you want to check it out!

Nic Brough -Adaptavist-

Story points are not supposed to be used as time measures, they are a comparative measure of estimates. "Relative difficulty" is a phrase one of my colleagues used.

I would strongly recommend you go back to using time tracking if you're starting to say "1SP = 1 day" and want to record Actual vs Estimate.

Or carry on using story points for estimation and velocity, but estimate and log time as the way to record actual work done.

David Childers

Thanks Trudy, this is more of a mental shift for me I think.

I DO understand story point usage/concept, I just feel we lose more than we gain by using SPs vs Hours.

We're committed though to giving story points a fair shake.

Another related question: How do you plan capacity for tickets with a low complexity but a significant time investment? For example, we have a designer that (let's say) we calculated his velocity at 15pts per sprint. When planning the upcoming sprint, he now has 8 tickets to make adjustments to a big batch of images...All tickets qualify as 1 story point because there's no complexity, but because of the sheer number he has to touch, might be > one sprint in total. TLDR 1 story point doesn't accurately reflect effort.

OR, is it standard to assign story points based on complexity * effort? So those one point tickets above would be recalculated to 5 each (1 complexity * 5 level effort)?

Trudy P Claspill

Story points should reflect all factors of the investment needed to complete the work; i.e. complexity and effort.

Dan -minware-

@David Childers do you see how answers seem to work their way back to time? More complexity or more effort = more time required.

If you think of story points 1:1 with days you can easily tell when something took longer than expected, regardless of complexity.

Keep it simple!

David Childers

Well, you're totally speaking to my bias for time as the true metric haha. I DO see the wisdom in your suggestion to keep it simple (1:1).

From what I understand, story points were conceived to separate time from work estimation - i.e. estimating something based on the effort/complexity rather than a finite scope (based on time).

To further complicate MY integration of story points into our projects, the newer management that is pushing story points prefers to hew as close to the "book definition" of how story points "should" be used, so are not amenable to equating points to hours.

If I have any great revelations as we get further along this journey, I'll post!

David Childers

Thanks Trudy, that does make me a bit more comfortable and will incorporate effort into our estimations.

Dan -minware-

Good luck - I look forward to the day that the bridge is gapped between management and the trenches!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

story-points