What is sizing?
“Sizing a project is about grouping its user stories based on agreed upon complexity factors”
Let me explain.
When you hear, T-shirt size M or L, what comes to your mind?
“May be a right fit!”
“30 or 40 inches of shoulder width!”
And some more… Depending on your experience with T-shirts.
Did the thought of its material, the time taken to make it, the cost of production, etc.. arise?
Only when somebody specifically ask, “how long would it take to produce a 100% cotton T-shirt of size M?”, we would start thinking about time, budget, material and so on.
Here size is used as a unit of measure, to standardize and group T-Shirts.
Similarly, when we want to group user stories into 3-4 categories based on certain parameters (similar to shoulder length in T-shirts), we may use any abstract scale like {S, M, L, XL} or “Number of Coke Cans” or Fibonacci Series(0, 1, 2, 3, 5, 8, 13..) or Geometric Progressionwith common ratio 2 (1, 2, 4, 8, 16, 32, ..) and so on.
Grouping the stories based on any of these scales, during initial stages of release, is known as sizing.
Why do we need to size our backlog? We don’t need to, if we could start working on the stories, with out having to provide any time and / or cost estimates.
What level of detail we need to size a story?
Usually, at a release planning time, we will have one liner user stories. Some of them might have some underlying assumptions captured.
Do we want more details to have a better accuracy?
Yes and No.
Yes: At times, when the scope is reasonably clear and the team has very strict timelines to commit to and are walking on a tight rope, we might need a bit more detail than an one-liner. The additional details help improve predictability. But, does not guarantee waste reduction as the effort spent on elaborating a story might go waste if that story was de-prioritized later.
No: Often times, there may not be enough details available at the time of release planning. Also, if the improved predictability is not a significant factor (possible in many situations), we need not spend too much time in elaborating the stories.
Caveat: There is no hard and fast rule on this. I’m talking from my experience.
How to chose a scale?
We touched upon a different sizing scales in an earlier paragraph. Irrespective of what we chose, we may be better of by limiting our set to 3 or 4 elements. Say, if we chose Geometric Progression then the set may be {1, 2, 4, 8}. If we chose T-shirt size, it may be {XS, S, M, L} and so on.
Since we are dealing with one liner stories at this stage, adding more elements to our set might just give a false sense of accuracy. In reality, it may not be so. Rather, we are better off accepting the uncertainty and ambiguity by chosing lesser elements so that grouping (or sizing) exercise becomes easier and less complicated.
Why do we have to size stories during release planning instead of estimating by days or hours?
First of all, to estimate a story in time scale, say days or hours, we might need details like the skills of the team member, the dependencies of each story, the sequence of stories to be played, etc. As we all know, often, during release planning, we may not have such levels of detail. But, we may still have to arrive at a tentative time line and budget. Experienced people, use their wisdom and come up with some estimates. But industry statistics show that its success rate is very poor, due to various reasons.
So, by accepting the uncertainty and the lack of details at this stage, we try to come up with a plan that could adapt in future.
Following the same T-shirt example, if we have to produce 100 cotton T-shirts of size M, we have the project size as 100 M Cotton T-shirts. For timeline and budget, we will identify the vendor for cotton material, tailors and processing people. We will get an estimate from them and arrive at a tentative time line and budget. If we change the vendors, our estimates would change but the size of the project remains the same.
Similarly, after sizing our software projects using any abstract scale, we could come up with a tentative time line and budget based on the team’s skill and availability, when ever necessary. Also, when the team changes, that is, the skill level changes, we might have to readjust the time line by adjusting the velocity (will be discussed in detail in subsequent blogs). The plan becomes more adaptive and reduces laborious rework.
How we do relative sizing?
One of the techniques I’ve used and had good results is as follows:
As a team, identify complexity factors (like number of DB calls, UX complexity – say # of devices and OS’ to support, third party integration, etc) for this release’ stories. Pick a reasonably familiar and medium complexity story and mark it as M (if we are using T-Shirt size, else pick an average size from our scale).
Keep this story as a reference. This reference story is marked for future sizing exercises also.
For the subsequent stories, compare them with the reference and group them on the lower or higher size based on relative complexity.
If we start with, say 40 stories, at the end of the sizing session, we might end up with a combination {for example: 8-S, 21-M, 6-L, 5-?}. The stories with ‘?’ need more info to be sized.
When do we resize a story?
- It is a better practice to resize the story only when the initial assumption of that story changes.
- A few teams, tend to resize their stories during sprint planning meeting. Their current knowledge gives them better clarity of the story and a better understanding of its complexity. So, they resize. But, the progressive knowledge influencing their story size will lead to skewed metrics as the other stories played during previous sprints were relatively sized against a reference while the resized story size is biased.
It is a good practice not to resize the stories when the initial assumptions doesn’t change.
Happy sizing!
Previous Articles in Product Visioning series:
Product Visioning : https://pm-powerconsulting.com/blog/product-visioning-5-steps-scoping-software-projects/
Product Visioning: 1. Elevator Pitch: https://pm-powerconsulting.com/blog/product-visioning-elevator-pitch/
Product Visioning: 2.1 User Persona: https://pm-powerconsulting.com/blog/product-visioning-2-1-user-persona/
Product Visioning: 2.2 User Goals, Pains and Gains: https://pm-powerconsulting.com/blog/product-visioning-identifying-right-target-persona/
Product Visioning: 2.3 Building Hypotheses using Persona and their Goals, Pains and Gains: https://pm-powerconsulting.com/blog/product-visioning-2-3-building-hypotheses/
Product Visioning: 3.1 User Journey Map:https://pm-powerconsulting.com/blog/product-visioning-user-journey-map/
Product Visioning: 3.2 Features-Advantages-Benefits: https://pm-powerconsulting.com/blog/product-visioning-fab-feature-advantage-benefit/
Product Visioning: 3.3 Prioritization of backlog: https://pm-powerconsulting.com/blog/product-visioning-3-3-prioritization-backlog/
