What are Story Points and how are they used in Jira | Story Points vs Hours estimation

Summary

This video script delves into the concept of story points in agile teams, addressing common misunderstandings. It explains story points as a method of relative estimation, contrasting them with absolute time-based estimations. The script uses examples to illustrate how story points are assigned based on the relative effort of tasks, not the time taken. It clarifies that one story point does not equate to one day's work and emphasizes the importance of agile teams using relative estimation for flexibility as requirements evolve. The video also provides a practical guide on how to apply story points in Jira, noting the difference between company and team-managed projects.

Takeaways

• 📏 Story points are used in Agile teams for relative estimation, which is quicker and easier than absolute estimation.
• 🔄 The concept of relative estimation involves comparing the effort of different tasks rather than breaking them down into smaller parts.
• ❌ A common misconception is that one story point equates to one day of work, but this is incorrect as story points are relative, not absolute.
• 👥 The effort required for a story point can vary between team members with different levels of experience.
• ⏱️ Time taken to complete a task is not the same as story points; the latter is a relative measure independent of time.
• 🔄 Agile teams prefer relative estimation because requirements often change, necessitating quick re-estimation and re-forecasting.
• 📈 Story points help teams to adapt to evolving requirements and provide stakeholders with updated progress reports.
• 📋 In Jira, story points are applied at the product backlog level and can be updated in the issue view under the 'Story Points' field.
• 👀 There's a difference in field names between company-managed and team-managed projects in Jira, which affects how you interact with story points.
• 🎥 The next video in the series will cover how Scrum teams use planning poker to determine story point values for their backlog items.

Q & A

What is a story point in the context of agile teams?

A story point is a unit of measure used in agile software development to estimate the effort needed to implement a product backlog item. It is derived from relative estimation, which is quicker and easier than absolute estimation by comparing items to each other rather than breaking them down into smaller parts.

Why is relative estimation preferred over absolute estimation in agile teams?

Relative estimation is preferred because it allows for quicker and easier estimation by comparing items to one another. This is particularly useful in agile environments where requirements can change rapidly, necessitating frequent re-estimation and re-forecasting.

How does the concept of story points differ from the concept of time?

Story points are a relative measure of effort and are not directly tied to time. The same story point can represent different amounts of time depending on the individual or team working on it. For example, a story point might represent half a day for an experienced developer but could take two days for a less experienced one.

What is the significance of not equating one story point to one day of work?

Equating one story point to one day of work would negate the purpose of relative estimation. It is a mistake because it does not account for the varying complexities and efforts required for different items, and it does not allow for the flexibility needed in agile development.

How do you apply story points in Jira?

In Jira, story points are applied at the product backlog level. You can update them by opening the issue, scrolling down to the story points field, and entering the appropriate value. The field name might differ based on the project type, being 'story points' in company-managed projects and 'story point estimate' in team-managed projects.

Why are story points important for agile teams?

Story points are important because they provide a flexible and relative way to estimate work effort, which is essential for managing the dynamic nature of agile projects where requirements and priorities can change frequently.

What is the relationship between story points and a team's velocity?

A team's velocity is the average number of story points they can complete in a sprint. Story points help in determining velocity by providing a measure of the team's capacity and productivity over time.

How can story points be used to plan a team's long-term release?

Story points can be used to plan a long-term release by estimating the total effort required for a release and then comparing it with the team's velocity to determine the number of sprints needed to complete the work.

What is the difference between a company-managed project and a team-managed project in Jira regarding story points?

In Jira, a company-managed project uses the field 'story points' while a team-managed project uses 'story point estimate'. This difference is important for using Jira features like JQL searches or Jira automation, where the correct field name must be used.

What is the next topic that will be covered in the series after explaining what a story point is?

The next topic in the series will be how scrum teams decide on the story point value for each product backlog item using an approach called planning poker.

Outlines

00:00

📏 Understanding Story Points in Agile

The video script introduces the concept of story points, a term often misunderstood in Agile teams. The speaker plans to create a series of videos to explain story points, starting with their definition and use in Jira. Story points are part of relative estimation, which is a quicker and easier method of estimation by comparing items rather than breaking them down. The example given compares two product backlog items, A and B, where B is estimated to be twice the effort of A, hence assigned two points. It's clarified that story points are not directly equivalent to time or days, as different team members might take varying amounts of time to complete the same item but agree on the relative effort in story points. The speaker emphasizes the importance of not confusing story points with absolute time estimates and suggests that teams should reconsider using story points if they equate them with days.

05:02

🔍 Agile Estimation with Story Points

This part of the script delves deeper into the practical use of story points in Agile teams. The speaker explains that Agile teams prefer relative estimation because it allows for quick and easy comparison-based estimations, which is beneficial as requirements often change in Agile projects. The script uses the example of items A, B, C, D, and E to illustrate how teams can rapidly estimate new items by comparing them to previously estimated items. The speaker then transitions to how story points are applied in Jira, highlighting the difference in field names between company-managed and team-managed projects. The video ends with a teaser for the next video, which will cover how Scrum teams determine story point values using planning poker, and encourages viewers to subscribe and engage with the content.

Keywords

💡Story Points

Story points are a unit of measure used in Agile development to estimate the effort required to complete a user story or product backlog item. Unlike hours or days, story points provide a relative measure of effort, which is less precise but more flexible and adaptable to changes in scope. In the video, the speaker clarifies that story points are not meant to represent a specific amount of time, such as one point for one day, but rather a relative comparison of effort between different tasks.

💡Agile Teams

Agile teams are groups that follow Agile methodologies, which emphasize flexibility, collaboration, and iterative progress toward a goal. The video discusses how story points are particularly useful for Agile teams because they allow for quick estimation and re-estimation as requirements evolve, which is a common occurrence in Agile environments.

💡Relative Estimation

Relative estimation is a technique where the size or effort of a task is estimated by comparing it to other tasks rather than breaking it down into detailed components. The video explains that this approach is quicker and easier than absolute estimation, which involves detailed breakdowns. It's highlighted as a preferred method in Agile because it accommodates the dynamic nature of Agile projects.

💡Velocity

In Agile, velocity refers to the amount of work a team can complete in a given time period, often a sprint. The video mentions that understanding story points is foundational to determining a team's velocity, which is a measure of their capacity to deliver stories over time.

💡Product Backlog

The product backlog is a list of features, enhancements, or bug fixes that a team intends to work on, prioritized by business value. The video script discusses how story points are used to estimate the effort of items in the product backlog, helping teams prioritize and plan their work.

💡JIRA

JIRA is a widely used project management tool that supports Agile methodologies. In the context of the video, JIRA is used as an example of how story points can be applied and managed within a software tool. The video explains how to input and update story points in JIRA for both company-managed and team-managed projects.

💡Planning Poker

Planning poker is a consensus-based, Agile estimating technique where team members make relative estimates by playing numbered cards face-down to avoid bias. The video script alludes to a future video that will cover how Scrum teams use planning poker to determine story point values for their backlog items.

💡Scrum Teams

Scrum teams are cross-functional groups that follow the Scrum framework, a specific type of Agile methodology. The video is aimed at educating Scrum teams on the proper use of story points, indicating that the concept is particularly relevant to this Agile subset.

💡Effort

In the context of the video, effort refers to the amount of work required to complete a task, as opposed to the time it takes to complete it. The speaker uses the term 'effort' to distinguish between the relative nature of story points and the absolute measure of time, emphasizing that story points are about effort relative to other tasks.

💡Estimation

Estimation in Agile refers to the process of predicting the amount of work or time required to complete a task or project. The video discusses the importance of estimation in Agile, particularly using story points for relative estimation, which is more adaptable to the changing requirements typical of Agile projects.

💡Release Plan

A release plan in Agile is a schedule that outlines when certain features or products will be delivered. The video mentions that understanding and using story points effectively can help in determining a team's long-term release plan, as it provides a basis for forecasting and adjusting delivery timelines based on team velocity and story point estimates.

Highlights

Story points are often misunderstood and misused in agile teams.

Story points originate from relative estimation, which is quicker and easier than absolute estimation.

Relative estimation involves comparing items to each other rather than breaking them down.

Story points are not directly equivalent to time or effort in days.

The example of product backlog items A and B illustrates the concept of relative sizing.

Different team members may take different amounts of time to complete the same story point.

Story points remain consistent regardless of the individual doing the work.

Agile teams use story points for quicker estimation as requirements evolve.

Story points allow for rapid re-forecasting in response to changing requirements.

In Jira, story points are applied at the product backlog level.

The story points field may be labeled differently depending on the project type in Jira.

Jira uses 'story points' for company-managed projects and 'story point estimate' for team-managed projects.

The next video will cover how scrum teams decide on story point values using planning poker.

The importance of not confusing story points with time estimates is emphasized.

The video series aims to clarify the use of story points in agile teams.

The video provides practical advice on using story points in Jira effectively.

Transcripts

story points are one of the most

misunderstood and misused terms with

agile teams and it's no surprise that

I've had a lot of viewers ask me to

create a video on this topic now there's

a lot to cover so rather than just one

video I'm going to give you a series of

videos where I cover everything from

what a story point is determining A

team's velocity and then subsequently

using it to determine the team's

long-term release plan so in this first

video I'm going to cover off what a

story Point actually is and how it is

used in jira are you ready let's do it

[Music]

[Applause]

[Music]

so what is a story Point well it comes

from an approach called relative

estimation and the big idea behind

relative estimation is that it is

quicker and easier to estimate if we do

so by comparing instead of by

deconstruction

so for example if we had two product

backlog items it's a lot easier to

compare the two and say one is the same

as the other or maybe one is bigger or

smaller instead of trying to take each

item break it down into little pieces

and figure out how much time will each

piece take

so let me give you an example imagine I

have product backlog item a and product

backlog Item B now if we ask the team

let's compare these two items are they

the same amount of effort and they might

say no product backlog Item B is

twice the amount of effort of product

backlog item a

so if we were to give

product backlog item a one point

what would product backlog item be

two points of course because we're

indicating that it's twice the effort

now what do I mean by effort a common

mistake that a lot of teams make is say

well doesn't one point just mean one day

and that's not correct

so let me give you an example so you can

see what the difference is between story

points and time

[Music]

okay so let's go back to my example of

product backlog item a and product

backlog Item B where we gave a one point

and B two points because it's twice the

amount of effort now let's say we had

two Developers

and one developer is much more

experienced than the other now the more

experienced developer if we were to ask

them okay how much time will it take to

do

product backlog item a they might say oh

you know what takes me about half a day

to do that so if a takes half a day how

long would it take them to do B

double that okay twice that it would be

a whole day

now on the other hand if we were to ask

the same question to the less

experienced developer they might say

product backlog item a is going to take

them two days okay it takes a more time

because again they have less experience

so if a is going to take them two days

what will be

B will take them four days twice the

amount of effort so the time is very

different depending on who does the work

but the story points remain the same

both agree that product backlog Item B

is twice the amount of product backlog

item

so I hope you can see there's a

difference between time which is what we

would call absolute estimation versus

story points which is relative

estimation

so if you have a team that is calling

one story point one day

you can go back to them and say why are

we calling it a story point and the

common response is that hey that's what

all agile teams do

so if your team is doing that a

suggestion just call it a day there's no

need to call it story points which would

just add more confusion

[Music]

thank you

okay so in summary you can see that a

story point is a relative estimate and

what's a relative estimate it's where we

are estimating by comparing items to one

another now why do Agile teams do this

it's because estimating by comparing is

a much quicker and easier way to

estimate

so for example imagine we had more items

to estimate if we know that a is one

story point and B is two story points

when we look at the next item let's call

it C we're going to compare to those

previous two and we might say hmm C

looks like it's about

three times the size of B but not quite

so we'll give it let's say Five Points

Now we move on to the next item this

one's a bit smaller item D here what's

the easiest way to estimate that one

when we're comparing we might compare it

to a and say look it it's probably about

half the size of a so let's give it half

a story point

and the last item here e

how would we estimate that one we might

say ah if we're comparing here it looks

like it's somewhere in between B and C

so if B was two points and C was Five

Points a number in between that might

make sense is three story points

so you can see how this approach to

estimating is much quicker because we

did not need to get into the details

about what's involved to implement these

items we didn't need to deconstruct them

as I said earlier now you might be

thinking still why bother using approach

which is quicker and easier it's because

when we adopt an agile approach our

requirements will emerge they will

evolve and change over time so naturally

if our requirements are changing

what's going to happen to our estimates

they are also going to change so as our

requirements our product backlog changes

we're going to need to re-estimate and

refocus so it's very advantageous to

have an approach where we can rapidly

re-forecast so that we can go back to

stakeholders and give them an update on

how things are progressing based on the

changes that have occurred

now that you understand what story

points are let's have a look at how they

are applied in jira

[Music]

when using story points we apply them at

the product backlog level so to apply

them in jira all you need to do is just

go to the backlog View and you'll notice

the story points appear on the right now

to update those points just open up the

issue scroll down and you will see these

story points field so you just click in

it change it to whatever the value

should be and tick to save now point to

note you'll see here that the field is

called story points

and it's called story points because I'm

using a company managed project now on

the other hand if you are using what

jira calls a team manage project let me

show you one of those okay so this one

is a team manage project you'll notice

it's slightly different so if I click on

this product backlog item and then

scroll down

the field is not called story point but

story Point estimate now that's a subtle

difference to note because again

depending on the project type you use

it's a different field and that means

when you use other features within jira

whether it's searching with jql or

creating an automated process with jira

automation or any of the other features

you'll need to make sure you pick the

right field name okay so just keep that

in mind when you are using story points

[Music]

foreign

so now you know what a story point is in

the next video I'm going to show you how

scrum teams decide what the story point

value should be for each of their

product backlog items by using an

approach chord planning poker so if you

don't want to miss out on that don't

forget to subscribe if you'd like to

support us or you found this video

helpful don't forget to hit the like

button and if you would like to be

notified when the next video comes out

hit that Bell icon otherwise thank you

so much for watching and I'll see you at

the next one