Hello wonderful people, how are you all doing? Can you believe that we are in December already, the last month for this year, and 2014 will soon be a by-gone. Time flies, doesn’t it? Well, the good news is that this is the month of festivities, lot of holidays, family time, Santa time, gifts and wishes time… its beautiful… a little cold but its okay, we still love it 🙂 I am sure you can tell that I am in the holiday mood 😛

Alright, lets get back to the agenda, but wait, the agenda is related to the holiday season. Well, sortta!!. Agenda is to learn about how to find out what size we are, so that we can fit into our best clothes and look the best in those holiday parties, right? 😉

When you go out for shopping, want to buy a T-shirt, you try different sizes and go for the one that fits you the best, right? Do you worry about what if you put on weight and the new T-shirt won’t fit you anymore? Or, if it goes the other way round, that you lose some weight and the T-shirt again doesn’t fit as good as it did when you bought it. I don’t think you do that, do you?

We do not want to worry about what will happen in the future, for the simple reason that we don’t know what is going to happen in the future. We can be anxious to know what future holds, but no matter what we do, we can not find that out, until the future becomes the present. It is impossible to tell, if you will gain or lose weight in the future, you can only predict it based on your current habits, you can work on it ensure that things go as planned, but there always will be an uncertainty and you will have to live with that. We make our decision of buying the T-shirt based on what size we are today, may be add a little wiggle room, but I am sure you will not buy an XL if you are M today. Am I right? or Am I RIGHT? 😉

The SIZING of user stories works the same way, we size the stories based on the knowledge we have as on date, based on what we know about the story today. Requirements/design may change in future, or we may find showstopper defects, all these have no relation to how we size the story. The size is determined by keeping in mind the complexity of the work, resource availability, skill-set levels, external known dependencies, or any other known factors that can play a role in the story’s development. Nothing UNKNOWN today will have any bearing on what the size should be.

In case things do change in future, requirements or design changes or critical defects crop up or any new internal/external dependencies are revealed, it may impact our sprint delivery, however, it still doesn’t call for a change of size for a story that is already committed to and is in-progress. This is captured as a lesson learnt and discussed in the retrospective session. It acts as a historical data for helping us size similar stories in future. And in case, the story is still under grooming and/or NOT committed to yet, the size can always be changed, based on the latest discoveries about the story.

Why Size?

It is a very good question to ask, why do we have to size the user stories? To answer this question, we first need to understand where do User Stories come from? User Stories are an end product of the process of decomposition of business vision. Although sounds simple, the decomposition process actually involves a lot of refining and hammering of the requirements. The vision goes through a series of stages to be broken down into nicely written user stories (we will discuss this in detail in another article about Product refining and Intake Process).

Vision –> Strategic Themes –> Portfolio Epics –> Program Epics –> Features –> User Stories

Now let us say that the leadership (senior management) wants to know how much time will it take for getting the vision implemented and out to the market, now these story sizes will come in handy.

• story points add up to give us the feature size, the feature sizes add up to form the epic size, epic sizes add up to theme size and theme sizes add up to give us the size and effort involved for getting the vision out the door (a simple roll up process), and
• from the teams’ velocities we know how many story points they can be delivered in a given sprint
• Putting the two together helps you come up with a more realistic estimate

Well, you may wonder how accurate these estimates are, may not be 100% accurate but definitely more accurate than SWAGs and not to forget that these #s are much more realistic, as they are deduced from the current and historical data.

Who should be Sizing?

Sizing is a 100% team activity and will not be effective if the all the team members do not actively participate. Each team member’s involvement in the sizing process is critical as each team member’s opinions and thoughts count. After all it will be them working on the story.

The Scrum Master facilitates the session, drives the discussion around the right size and manages the difference in opinion amongst the team members, if there is any. He helps the team members arrive at a common consensus on what the appropriate size should be for a particular story.

Product Owner doesn’t have much of a role to play in sizing apart from clarifying any questions that the team members may have.

What can be and should be sized?

Generally, it is User Stories that we size as part of the Grooming and/or planning sessions. When it comes to defects, some teams size them and some don’t. Those who do, believe that defects are an additional piece of effort and hence should be sized. And those who don’t, believe that defects are an offshoot of the user story and hence should be accounted for within the size of user story itself, as we can not call a story DONE if there are defects around the same.

I personally understand and agree with both the approaches, as end of the day the objective is to get the defect resolved, the focus is PRODUCT and not the PROCESS.

If we are still itchy about this topic, we can always consider the following factors to decide which approach will work best for your team:

• Type of defect –
  • is it a regression defect, or
  • is it a production defect, or
  • is the defect found in the same sprint in which the user story is being worked upon, or
  • is it for a user story from the previous sprints.
• And it also depends on where the team’s comfort lies

No matter which approach you go with, just BE CONSISTENT as inconsistency will lead to misleading metrics.

FEATURES and/or EPICS can also be sized if need be, using relative sizing. However, keep in mind that bigger the item we are trying to size, less accurate these sizes will be. Roll up approach is, any day, a better approach to adopt, if feasible.

So at this point we know why we need to size, what we need to size and who should be sizing. All that remains to find out is – How do we size? – COMING SOON 😉

Happy Reading!

– Nirbhay Gandhi