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
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.
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.
Hi, every brand's t-shirt size differs at least 1 or 1.5 In than other brands. but the main thing to consider while finalizing size is the height of the consumer. usually, a small size t-shirt is made for a 5.5ft-5.7ft person and large size is made for a 6.4ft.
Hi everyone! Are you interested in beta testing Atlassian University’s newest (unreleased!) training course? We’re looking for 15-20 volunteers to test our newest training course, Basic reporting...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events