How to T-Shirt Sizing or Bucket Sizing to Size a Story in JIRA? Is that even possible ?
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.
Portfolio also does not allow it?
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 ?
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
Just wanting to clarify, story points are dependent of time.
Did you mean Independent of time?
@Bill Tanner No. In a previous post above, one mentioned that story points are independent of time. When in fact, they are time based.
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.
It looks like you're new here. Sign in or register to get started.
