How can a team new to Scrum/Story points assign points to the first baseline user story?
Hi,
I'm working with a team that is newly formed together AND new to Scrum AND estimating user stories in points rather than hours.
We are planning on using the Fibonacci sequence to size up the different stories and we know we're supposed to pick a baseline story and estimate it to then estimate the other ones relative to the baseline etc…
We've already grouped stories together (i.e: distinguished large vs medium vs smaller stories roughly speaking), however, we're struggling to decide how many points to give the very first baseline story EVER (either a small or medium one) as we do not know how to quantify or agree on what a point is "worth".
Should the team pick a random number that they like to assign to a medium or small story that they understand the best and start from there? (i.e: 3, 5, 10 or whatever, doesn't really matter). Is there a guide to what that very first number should be?
From a personal point of view, I was also thinking that they should pick an odd number and/or big enough number on the Fibonacci sequebce to help them avoid relating points to hours too much. Any opinion on that?
For reference, we're planning to work on a 2-weeks sprint cycle.
Thanks a lot for your help.
P.
Why do you want to estimate in points rather than hours?
Estimates have relatively limited value. They are useful for helping a team to check if a Product Backlog Item has been decomposed enough to fit within a Sprint and to check the overall size of the selected Product Backlog Items for a Sprint against the team's capacity. If you're spending so much time with figuring out how to estimate using a particular method, perhaps the method is not appropriate for use in your context.
A common approach is to pick the smallest one and give it 1 point. And then relative to that one, appoint the other points.
But, I'll add the mandatory questions/suggestions: have you looked at "rightsizing" or #NoEstimates? How about just starting, and later on adding a Service Level Expectation based on cycle time and throughput (that's from Kanban)?
Either way, do not put too much value in story points, they are only estimates, and should only be used for planning. If possible, do not communicate the points/velocity.
I agree with Mario, pick smallest story and give it point 1, then relatively give points to other stories.
Story points is teams decision, ideally not related to hours.
Story points are used to make relative estimations, rather than accurate estimations in hours.
Gradually team will be comfortable with story points estimation with inspection and adaption.
Estimates have relatively limited value
Thomas hit the nail on the head. The conversation is usually much more important than the number. In fact, change the conversations to focus more on value of a PBI rather than points or velocity. Focus more on achieving a Sprint Goal rather than velocity.
Scrum doesn't mandate you use points or relative estimates. Throughput (the number of Product Backlog items completed per Sprint) might be all that is needed, and might free up time to focus on valuable work. Experiment to see what works best for your team.
If your Developers decide to go with Fibonacci, they always have the Sprint Retrospective to inspect and adapt their estimation. But accept the fact that in complex work, the estimates will hardly ever be exact.
Should the team pick a random number that they like to assign to a medium or small story that they understand the best and start from there?
If this helps the Developers to make a forecast, why not? The purpose of estimation is to help them get their arms around how much work they can take on in a Sprint. That's it. Everything else reduces to value delivery and empirical process control.
Everyone has already said most of what I wanted. But I want to add a little bit.
Story Points are estimates. Estimates are guesses made based upon information known at the time of making the guess. As work begins, new information will be obtained that could change the estimate. This is especially true to a team that is new at estimating. Do not fall into the bad habit of updating estimates as new information is uncovered. That is a wasted effort.
Also want to state that after your Sprint begins, estimates are no longer useful for anything. They should not be used to determine a team's velocity. They should not be used to measure a team's performance. They should not be used to measure an individual's performance. They should not be used to compare one team or individual to another.
I hope you see that they can be useful but for a specific purpose. To give the Developers a sense of the amount of work that can be done in a Sprint time-box.
Hello @Daniel,
Sorry, may I please ask you a quick question about your previous statements? (I am not sure if I am allowed to do so as it would not be 100% related to the original topic, if not, please tell me and I will avoid that next time)
Do not fall into the bad habit of updating estimates as new information is uncovered.
To give the Developers a sense of the amount of work that can be done in a Sprint time-box.
For the purpose of better planning what you might do in the next Sprint, wouldn't make sense updating an estimation in case, for instance, new important information arrives (or the item has been already started and someway tested, yet still not "done")?
This is the only guidance provided in the Scrum Guide for something that is not completed during a Sprint (emphasis added by me).
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
There is no use of the word "estimate" or any variation of it in the current version of the Scrum Guide.
However, the Product Backlog represents all of the work that is needed to be done to the product. One of the attributes mentioned as being part of a Product Backlog Item is size. But there is no instruction on how to do that. Only this statement:
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Remember that the Scrum Guide does not provide any procedures or process. So your team decides is the best process for them. If they feel re-estimating work not completed during a Sprint is best, then they should do it. Remember that estimation is just an exercise to help the Developers decide if they have a chance of completing all of the work they choose to add to the Sprint Backlog.
When I stated "Do not fall into the bad habit of updating estimates as new information is uncovered." I was mostly referring to updating estimates for items during a Sprint. That is because an estimate is no longer needed after a Sprint begins. However, I am not opposed to re-estimating when work is not completed at the end of the Sprint. But I do not advocate for it. I just support my team should they feel it beneficial.