Useful Tips & Practices for Sizing Agile Stories

In Agile story sizing, there are some basic concepts and useful practices applied to every development team, no matter what kind of project they work on, how many members there are in their teams, and the experience they have. This guide intends to clarify some important aspects of Agile story sizing as well as providing some useful practices based on real-world experiences.

Size vs. Time; Size is simply the “bigness” of a job that doesn’t represent any time value. Given that the entrusted job is traveling to Ankara from Istanbul. There are a lot of different vehicles and routes you can choose to fulfill this mission. Some people may prefer flying whereas some others take a train. Or others may choose to travel in his/her car. The arrival time will be different for each of these persons. Besides that, if you travel a second time in your car, it takes even less time since you will be more experienced on the route. So, as seen, the arrival times are not the same, but the distance is always 450 km. The distance here is the size of this job. And, the size is the same every time, no matter who does the job or what tools or vehicles are used.

Same story point for the same type of job; A story point that is given for a job is not expected to be different than the same type of job sized a bit earlier. Let’s say, there was a 3D secure implementation job for Bank A which was sized as 8 points a few months ago. And now, another 3D secure implementation job is going to be sized for Bank B. In this case, the second job is also expected to be sized as 8 points, if there is nothing exceptional. The experience gained over time doesn’t change the size of the job. There should be standard sizes/points for the same type of jobs. Thus, it will help Agile teams to find out their capacities for doing work and measure their performances more accurately in the long term.

No designated developer; It is definitely a bad practice to assume that specific kinds of jobs are done by specific developers in the team. By doing so, it will end up by sizing the stories according to who is going to do them. This means that the less experienced the developer is, the higher the story will be sized or vice versa while the “bigness” remains the same. The right way of doing this will be not assigning any jobs before/during the sizing session and all the members will size them independently and come to a common ground.

Refer to earlier stories; During sizing sessions, it is a good habit to refer to the stories sized earlier, especially for the controversial cases. Comparing a story to an earlier one will make the decision-making process easier. In such cases, asking questions like “is it a bigger job than the earlier one?”, “Is it more complex?”, “Why are we sizing it higher/lower?”, etc. will enable you to find out the real size of the story.

First sizing? Define the lowest story point; If it is the first sizing session for the team and there is no reference story to take as a base, coming up with a made-up story would be very practical to set a starting point. In such cases, the best practice is defining the lowest point (which could be “1”) and also defining the effort it represents for the team. For example, receiving a single input from a web page and writing it into the database can be accepted as point 1. So, by taking this as a base, the team now can come up with a relative point for its first story. Once the first story has been sized, the rest of the stories can be sized comparatively.

A brief review of stories; It is very helpful for Agile teams to take a brief look at the stories before the sizing sessions. Thus, all the members of the team will have a general idea for each story, and this will help to keep the sizing sessions shorter. For this purpose, before sizing sessions, the product teams (PMs or analysts) can inform the team about the stories to be sized via email, etc.

Ordering stories; Another important thing for better story sizing is ordering the stories by their “relative sizes” before sizing sessions. In this process, the business teams size the stories roughly and t-shirt sizing is the best tool that can be used for this purpose.

It’s always good to start sizing sessions with relatively smaller stories. Thus, the team can be aware that the following stories are (most likely) not smaller than the previous one. Eventually, this will help teams size their stories more accurately and faster.

More clarification when stuck; If the team has difficulty in sizing a specific story and the developers are coming up with “weird” story points, you should consider a quick clarification on that story. If this conversation takes more than a few minutes, it would be better not to size it until a more detailed analysis and clarification are done.

However, if it is only 1 or 2 developers who have made estimates that are much higher or lower than the rest, then they are expected to explain why they have done so. It may not be so frequent, but in some cases, they may point out some risks or complexity that the others couldn’t see. And, this may help the team to do a more accurate sizing.

Why use Fibonacci? The time-based estimate is the first thing you need to avoid in Agile story sizing. Even though Agile teams use numeric or t-shirt sizing scales, most of the time it ends up by linking these values with some specific durations. For example; 4 points may start referring to a day of work on a linear scale (0, 4, 8, 12, 16…),. After that, it is not avoidable to start linking 8 points with 2 days, 12 points with 3 days, and so on… It wouldn’t matter if you were using a t-shirt sizing scale either. As long as the items in the scale have a ratio in between, it will be inevitable. In such cases, if person A finishes a job sized 8 points in one day, person B may think that his 16-point job has two days to be done, even though it takes less than that. On the other hand, the Fibonacci sequence being the most popular sizing scale has no ratio between its values (except 1 and 2). This makes it difficult to link to duration or man-day values. The Fibonacci sequence can also be very useful to represent the uncertainty of a job as it increases in expanding ranges.

How to decide the size of a story? When sizing a story, the parameters given below should be considered;

1. Effort (Volume of Work to Do): How much coding or testing does the job require? We can ask questions such as;

2. Complexity: The challenge/difficulty the job has. Ask questions such as;

3. Uncertainty (Risk): Represents the points that are not clear/certain enough in the job. The questions as given below can be asked;

A practical guide for sizing stories;

Thanks for reading 🙂

First Release on Medium