How to estimate story points for ServiceNow related stories?

[major li]

Hi Community,

May I know how do you do the effort estimation in your sprint planning?

By definition, A Story point is a singular number that represents:
• Volume: How much is there?
• Complexity: How difficult is it?
• Knowledge: What do we know?
• Uncertainty: What's not known?
Story points are relative and not connected to any specific unit of measure.

The purpose of the story points is to reach an agreement within the team.

But it will be hard to estimate by gut feeling. Is there any lookup table or other quantified way to help the team?

Thank you. 

[GlideFather]

Hi @major li,

there's no universal answer to this, the story points must be defined by each team, company, or project...

I've see story points that represented hours 1 point = 1 hour, or set where 1 pt was up to 2 hours, 2 pts up to 4 hours, 3 pts one day, 4 pts until the end of this week and 5 pts more than any of the before. Another project had fibonacci series 1, 2, 3, 5, 8, 13, 21.... 

It's not transferrable, it must be agreed and well explained to all the team members. I saw also one-week sprints as well as 3-weeks sprints. 

As said before, every single team will have different preferred properties.

[Dr Atul G- LNG]

Hi @major li 

As a BPC, I participate daily with the PO and development team in story estimation. SN provides some common guidelines, but there is nothing strictly defined or written that a story must follow a specific number of points. Based on my experience, we consider the following parameters during story estimation:

• Nature of the story — for example, whether it is related to a flow, email, or integration.

• Configuration requirements — such as script usage or variable usage.

• Testing effort (done by the developer).

• Developer experience — we ask all developers to provide their points. If there is a large gap (for example, one developer says 3 points and another says 8), we ask for justification and the reasons behind the low and high estimates. We then decide based on discussion, and sometimes go with the average.

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

[Jennifer Metz]

Hello @major li,

This really is a question as old as time.

In my experience working with different clients and project managers, a lot of teams try to make story points easier by converting them into time, like one hour equals one point. It feels like a shortcut, but it is not the recommended or most realistic way to do estimation.

The purpose of story points is not to measure time. It is to measure effort relative to other stories so the team can agree on priorities and scope. It also helps developers make good decisions on picking up extra work when time opens up unexpectedly.

As a developer, I may hit a blocker on one story that takes time to resolve. In the meantime, I might grab a smaller story that I know will not overwhelm me once the bigger one is unblocked.

Using a strict quantitative system defeats the purpose. Story points were created because time based estimates are often unreliable. Developers have many variables to deal with in a story such as complexity, testing, integrations, unknowns, and environment issues.

There really is no lookup table that works well across teams. What works better is agreeing on a baseline story everyone understands and estimating everything else relative to that. Over time, the team naturally becomes more consistent and aligned. If estimation becomes more about hitting numbers than about collaboration, it can hurt morale and create unnecessary frustration instead of helping the team plan realistically.

In my opinion, the best thing you can do is talk with your team, agree on what feels right for everyone, and stay consistent. The exact scale matters far less than shared understanding.

Hope this helps!

[GlideFather]

@Jennifer Metz, this ☝️💯