relative size of US versus velocity
Hi,
A size of US is relative. It only informs which UStories have the same size, which ones are bigger, which ones are smaller. But no information how many times other UStories are bigger or smaller. It explains why we can use t-shirt sizes for an estimation.
But when it comes to a planning we count sizes, sum them up, compare to the current velocity, finally pick out. Hence when we have the velocity 4 points and US1, US2, US3 with their sizes 4, 2, 2 respectively, we will take either US1 or US2 with US3. So there is assumption US1 is 2 times bigger then US2 or US3.
is there a contradiction or inconsistency?
BR,
Bartek
Hello Bartek,
Allow me to share some of my understanding....
In the example you are offering, to some degree, yes we can say 1 item is twice as large as the other. However, this is comparing fewer items. There is neither contradiction nor inconsistency with just these few items.
It also depends on how the time sizes items.
Another team may say --
Small = 1
Medium = 5
Large = 8
Now, when it comes to planning and the team is forecasting a numerical value of 4, let's consider your example.
User Story 1 = 1
User Story 2 = 5
User Story 3 = 5
In addition......
User Story 4 = 1
User Story 5 = 1
User Story 6 = 8
What do you think the Dev Team will pull during Planning?
(we can all figure this out, but its just to think about something else.)
.
.
.
On another note, I would like to bring awareness to other ways of sizing such as Fibonacci --
http://en.wikipedia.org/wiki/Fibonacci_number
If you notice, as things get larger, there isn't a clear way of telling what is "twice" or "thrice" as large as the other, etc. This is not to suggest your Dev Team should be using this.
Question:
Is the Dev Team using just 3 sizes right now? How many Sprints have elapsed?
> is there a contradiction or inconsistency?
Not really, because (like T-shirt sizes) story points are estimates. They are numeric, which makes them more precise, but it doesn't make them any more accurate.
[code]
<caveat>
I am also fairly new to Scrum
</caveat>
[/code]
Story pointing can be a useful way for a Scrum Team to make the amount of effort represented in a Product Backlog transparent and to estimate the amount of effort will be required to complete a Product Backlog Item. It can also be a valuable trust builder between the Product Owner and development team; as the team estimates effort more and more accurately, the product owner can communicate more accurately to Stakeholders what work can get done and when.
As Ian said, estimating effort is about accuracy not precision, grouping on a dart board is less important than getting nearer and nearer to the bull's eye.