How to T-Shirt Sizing or Bucket Sizing to Size a Story in JIRA? Is that even possible ?

[Charu Sharma]

How to T-Shirt Sizing or Bucket Sizing to Size a Story in JIRA? Is that even possible ?

[Warren · Accepted solution]

Hi Charu

If you're asking whether you can store the outcome of T-shirt sizing in Jira, you would need to create a custom field for it, because the standard Jira Story Point field uses the Fibonacci numbers. 

[Charu Sharma]

Portfolio also does not allow it?

[Charu Sharma]

Also since we are new to story points and capacity planning,  can you please acknowledge if i've correct understanding about them for sprint planning ?

Here is how our org. plans to work :

We would estimate story points using Complexity Bucket Technique and Fibonacci Series.

To estimate a story, it will be broken down into tasks and team will collectively brainstorm on complexity (Low, Medium, High) of the story considering following buckets : UI, Business Logic, Integration & Testing.

Basis this complexity, team will size the story has XS or S or M or L or XL and allot the corresponding number from Fibonacci series as below:

1           2        3        5       8       13

XS         S       M       L       XL       XXL (Epic)

0.5D     1D    2D      3D    4D      This big size of story should be an epic ideally.

We have standardized # of days required for XS, S, M... size of story for all projects

On the other hand we will do team capacity planning and compare it with story points for sprint planning :

If there are 5 developers in a team (2 dev + 2 Sr Dev + 1TL) and there are 6 hours in a day (excluding meetings) and 5 days in this week, with no public Holiday. Capacity of this team for 2 weeks sprint will be = 5 * 6 * 5 *2  = 300 hours.

If this team gets 4 XS + 7M + 3L + 3XL story points in a sprint = 2D +14D + 9D + 12D = 37D = 37 *6 = 222 hours.

This clearly shows team with 300 hours of capacity, has got 222 hours of work, which is easily achievable.

Please acknowledge if my understanding about story sizing & capacity planning is correct ?

[Warren]

I have never used Portfolio, so can't answer about that.

Firstly, Story Points should be independent of time, so there shouldn't be a direct link between them. Secondly, if you're mapping T-shirt size to Story Points, why not just use Story Points??

You should either use story points or time for planning, but don't mix them). If time, then your description above is fairly accurate - add up the hours each team member has in the sprint, then estimate each task (or sub-tasks) in hours and fill the sprint.

For story points, you will use the average velocity of the last 3 (or 6 or ...) sprints to know how many story points you can achieve (your "capacity"). Estimate each parent item (NOT sub-tasks) in story points, then fill the sprint. For the first couple of sprints, before you have an average velocity, it's more of a guess and you may over- or under-commit, which is fine.

I hope this helps to make it a bit clearer

[Charu Sharma]

Hi Warren,

Thank you for your quick response.

Please help me clarify that if story sizing cannot be used for planning of the sprint, then what is the use of story points?

Our projects have adhoc tasks also, despite of just 2 weeks sprint. We do not want to measure velocity of a sprint, that is, we do not want to know how many stories were covered in a sprint. Instead we will be using cycle time to measure team's performance.

I fail to understand the use to story points wrt sprint planning.

[Mark Grundman]

Story points are used by the development team as a way of identifying the relative size and complexity of a deliverable based on previous work they have done.   

As time passes, a team will establish a "velocity", the average number of story points they complete per sprint.  Note that each sprint should only count the story points of items that actually meet the definition of done, there is no partial credit for half-done things.

A product owner can use the team's velocity to create an approximate roadmap of how much of the backlog can be completed each sprint to provide stakeholders with an estimate of when a feature could potentially be released.

Story points can also be used as a conversation starter piece between the dev team and product owner/customer.  e.g. If the deliverable the customer is requesting with all of the features/acceptance criteria is causing the dev team to point the backlog item high, negotiating with the customer to identify if any features are "gold plating" that could be removed may help reduce the points associated with the backlog item and thus reducing costs while increasing the potential for the item being completed in its forecasted sprint.

There's a danger in attempting to associate story points into hours especially if you are working with multiple teams.  The way each team associates story points to a backlog item will be unique based on multiple factors, including: type of work being consumed by the team, the team's ability level, and how a team has previously scored backlog items.  By associating hours with the story points, it can create the false realization that one team is working harder than another or is producing more than another.

On a side note, I actually prefer to use throughput over velocity for forecasting and road mapping.  The difference is that throughput is simply counting the number of backlog items completed each sprint vs. summing the amount of story points completed each sprint. I tracked the data for over a year and found that there was minimal variance in the throughput of the dev team from sprint-to-sprint where as the amount of story points completed each sprint could vary greatly. 

[Jason Chayer]

Just wanting to clarify, story points are dependent of time.

[Bill Tanner]

Did you mean Independent of time?

[Jason Chayer]

@Bill Tanner No. In a previous post above, one mentioned that story points are independent of time. When in fact, they are time based.

[Mark Grundman]

It's possible I'm misunderstanding but if story points are time based then why not remove the confusion and just use time for your estimates?  

I thought the purpose of story points was for a team to do relative estimating of backlog items based on a number of factors such as level of effort compared to previous items, complexity, risk, and uncertainty.  Time isn't included in this because that is calculated via the team's velocity (average number of story points they can complete per iteration). 

I've seen orgs use both methods successfully (estimating using time or estimating using points) so it all depends on what works for you.  However, it seems like associating story points with time is contradicting the intent of using points in the first place. 

[Jason Chayer]

My aim for the post was not to add confusion, or start a debate. I hear often people say that story points do not have time associated with it, when in fact, that is how you get to a story point.

An example, if I estimate a task for 1 story point. To determine that story point, I have to put some value on that.

@Mark Grundman - your understanding is correct. You can disregard my statement and keep using story points if you do. I find story points valuable and have used this approach often.

[Jessica Ives]

My formula for story pointing is unknown + risk + complexity = story point.

This then isn't time-based nor should it be because each team has a different perspective on those 3 areas in the context of their skills and other factors. Over a few iterations, you can then assume that the average velocity of points is equal to the length of the iteration (say 2 weeks) for one team but not another.

For anything above a story I've found T-shirt sizing works best and then using the relative sizing exercise to rank those larger bodies allows us to understand roughly the work required. I usually do this with all the scrum teams not just one. Each team offers a different perspective to the conversation. 

[Jason Chayer]

I agree with your formula above, and that should always be taken into consideration when estimating a task. This is why I like story points, it leaves room for flexibility.

As you mentioned, a story point could be different for different teams. But in the end, it is still time based.

How many story points can get done within a certain time period (sprint.)