Category: ways of working

Traps to watch out for while using story point estimation

So far we’ve highlighted a few antipatterns of story point estimation that you should be aware of. We’re now concluding this series with a callout to the most common traps to watch out for while using this estimation style. 

Trap 1: Assigning points to every activity

Many XP teams often give points to all their activities – even those unrelated to the core activity of writing code. You’ll see them creating a 1-pointer for a meeting or another 2-pointer while coordinating with someone, and so on. This is problematic because not only are you tracking everything you do, but you are calling it velocity!

The real purpose of velocity, we reiterate, is to show how much your team can do in a given period of time. And this “how much” is essentially how much software you can build. At the end of the iteration, you should be able to sum up all the completed stories and say that the team can do 10 points (for example). You should then progress to discussing possible impediments, overcoming them, and ways to improve velocity. 

Tip: Keep points to only about writing code 

Velocity must strictly be about software and writing code – never about how many meetings you attended or emails you sent, even if those are important activities. If you give points to all the activities done in your 8 working hours, the velocity will only highlight the fact that you put in 8 hours a day or 40 hours a week. There will be no insights into how much software you’re able to build in that period, thus obfuscating the purpose and value of velocity. 

Trap 2 – Accommodating QA estimates along with dev estimates

At some point, even mature XP teams find themselves in a scenario where someone engaged in a supporting activity to development, most commonly QA, will question how their time requirement is getting accommodated in the overall estimation. The QA may be looking at a story that’s complex to test even if it’s simple to develop. They know they will need more time than what’s been estimated and raise a flag. They may ask for a larger size for that story, and denying them that could lead to ill-will in the team. 

In such a case, should the devs do one estimate and the QAs do another and you add it all up? No! That’s the worst way out, because this will instantly kill any relativity you may want to maintain in your backlog. 

Tips: 

Consider only the dev estimates 

The Theory of Constraints advises estimating the bottleneck, which is typically writing code. What a PM or a BA or a QA does is valuable, but it’s only writing code that should figure in your estimation. You can assume everything else will be proportional to that. A story that’s larger to build will naturally be more difficult to analyze or test or deploy into production. So, keep it simple, and estimate only the development. 

Treat exceptions as just that, but investigate trends 

However, your backlog can have stories that need to be treated differently. A story may require complex analysis even if its algorithm or logic is simple to implement. Or there could be a type of story that’s quick to do, but its impact is across several different places and testing will be arduous. Our advice here is not to worry about such exceptions. Size is based on pure complexity and your velocity will reflect that that particular story took longer although it was not very complex. 

However, if you see many stories that have disproportionate effort compared to complexity, then it needs attention. Ask yourself questions like: Is there an opportunity for automation in the face of multiple manual changes? Can we restructure the code such that we follow the DRY (Don’t Repeat Yourself) principle? Investigate such patterns thoroughly and address them at the right time.

Adjust capacities of the team to meet exceptional challenges

If you are building an application that needs to work across multiple device sizes and browsers, then, potentially, testing can be more complex than development. Some teams may argue that their constraint is testing rather than development and a way to resolve that would be to estimate the testing effort and assume that development will be proportional. 

While this is the correct response theoretically, it might be an unfamiliar and difficult approach for many. Instead, adjust capacities of roles in the team. In the above example, you could add more testers to take care of the various devices and browsers and work it in such a way that development complexity remains the constraint because that is what people are familiar with. 

Trap 3 – Spiking with no limits 

Spikes are small experiments that you could do when you don’t know the answer to something or how to implement something. For example, you’re integrating with some third party component and you know so little about it that you can’t even estimate the time it will take. To arrive at that estimate itself, you may want to first play around with that component. That is spiking. Spikes have an important role to play in the project lifecycle. But it’s critical to not let them turn into endless rabbit holes. 

Tips: 

Time-box a spike 

Manage spikes by time-boxing it. Allocate a definite time period and at the end of that, you should know what to do next. Since at least one of your developers will be playing that spike for that period instead of working on a production story, take that capacity away from your velocity and make adjustments. Velocity commitments for that particular iteration could be lower than usual because of the spike. 

Assign a size to a spike 

You can also use points. We’ve worked with the thumb rule that any spike should be a Small. While it is cheating a little because we are in a way associating size with the time expectation, it does help limit the time that people could spend on that spike.

Trap 4 – Creating stories for supporting activities

An extension of the above trap is that some teams create a separate story for activities that will eat up a developer’s time – such as technical analysis or proving out the best strategy with testers, etc. All this is time consuming, but it’s distinct from writing production code. 

Tip: Call them tasks, not stories

We insist that stories be used only to represent code that’s getting built. That must be the sole definition of a user story. Call anything else that will require a developer’s time as “tasks”  and call out that the team will be short of capacity in that particular iteration. 

Trap 5 – Creating 0-pointers

We’ve seen previously that as you become familiar and efficient at completing stories, you subconsciously start downsizing them. This behavior can leave you with 0-point stories (downsized from a previous 1-point). Despite its seemingly negligible size, the story will still require time and effort. But you’re discounting the velocity for that because it seems too small to even count. This leads to a tricky situation: your productivity has improved because you are getting better at your work, but your velocity does not reflect that. 

Tip: Keep in sight the original sizes you started out with

Keep a reference set of stories that have the original sizes from your first estimation exercise. Compare your current set to those and then bucket them in the correct and relative sizes. This will avoid random 0-pointers that you think require no time, but add up to the velocity. 

Trap 6 – Making the velocity math work…somehow

Often you may convince yourself that you will protect your velocity commitment no matter what; that you will sum up all the activities that add up to that velocity and somehow make the math work. What that really translates into is that you’re shying away from critical conversations. If you find yourself spending more time today doing tech analysis, for example, it could be that complex features are the trend going forward. You then need to talk about addressing that trend by adding developers or calling in relevant experts if required. 

Tip: Engage in right conversations at the right time

Surface the issue for the whole team and the stakeholders so you’ll get more options. Even if the options are not viable, at least there will be clarity about the nature of work that will go into building your software right. At all cost, refrain from contrived efforts to make it to the velocity numbers. It will not reveal the true state of the project and prove detrimental. 

The key takeaway

Be vigilant at all stages of the project in order to catch downward trends. Agile strives to uphold transparency, clarity and visibility in the project and your way of working. Having meaningful conversations as needed will ensure these attributes. This will go a long way in successfully forging a solid relationship – strongly rooted in trust and reliability – with your client stakeholders.

Estimation antipattern – Losing relativity in the backlog

In this article, we’re going to explain a common phenomenon we’ve observed around losing relativity of the sizes of the stories in your backlog. This is an antipattern that could lead to your team feeling a sense of pressure because despite your productivity having improved, the numbers do not show that–thus raising a concern among stakeholders.

What is this antipattern?

If you’re on a long-running project that carries over multiple months or even years, your team begins to gain familiarity with the tech landscape, the domain, the environment in which they work, and the actual work they are doing. Over time, your ability to get work done improves. However, the velocity does not reflect that (and we’ll get into that). There is no data to match your feeling of getting more productive or effective. The velocity numbers remain similar or dip or oscillate. 

The root of this antipattern lies in incorrect sizing. The current sizes are not in sync with the relative sizes that you originally came up with, say, 6 months ago and that is why the velocity doesn’t reflect your improved productivity. 

Explaining it with numbers 

Let’s do some math here. Six months ago, you could complete 10 “medium” sized stories (2 pointers) in one iteration and so, your velocity was 20 points. Now, say you’ve got twice as productive at doing this work so you are able to do 20 “medium” stories in an iteration. But because of your familiarity with the application you size these “medium” stories as “small” (1 point) stories. The net effect is that your velocity will remain 20 points.

The velocity doesn’t show your improvement because your story sizes are not relative to what you started out with. 

Understanding using an analogy 

The analogy of a pizza works well to understand how we end up messing with sizing. As a child, you were barely able to finish a small pizza. As a teenager, you could easily devour an entire medium-sized pizza by yourself. Did the pizza size change? No! The 6-inch pizza remained the same. What changed was your appetite and ability to eat pizza. 

Connecting that to stories, the size of the story remains the same from what you’d estimated 6 months ago. Now, it seems smaller because of your enhanced ability. In your mind, a 2-pointer now feels more like a 1-pointer. 

The “How big” and “How fast” get mixed up, leading to the antipattern

To understand the “why”, we’ll revisit the process of story point estimation. Time-based estimates go wrong because they ask one compound – and incorrect – question: “How long will this take?” Story points replace that with 2 meaningful questions: “How big is this task?” and “How fast can it be done?” And then answers each question independently. 

The errors in sizing and losing the relativity of the sizes occur because the teams start to mix up these two questions. Something seems smaller (and easier) than before, not because it is indeed smaller, but because you’ve got better at doing it. The distinction between the two questions and the objectivity of each are lost. 

This mixing up questions happens when teams begin to consider only the current set of stories or the most recent ones during the sizing exercise. Stories done in the past are ignored. The real meaning of a 1-pointer is lost. It had a certain definition 6 months ago, but that changed over time, leading to this antipattern. And when clients do not see any improvement in the velocity numbers, they get restless: “You’ve been on this project for such a long time. What do you have to show for it? How do we get to see that your productivity has improved?” As you grapple with these questions, you find yourself stuck in the whirlpool of pressure and self-doubt – those same negative behaviors that we said don’t happen with story point estimation. 

Ways to avoid this antipattern 

Maintain a set of reference stories as examples of what Small, Medium, or Large stories look like. That way, when you get a new set of stories to estimate, you will not lose sight of the older, original sizes you set out with. You will avoid downsizing and your velocity, too, will reflect the correct picture. The improvement in your productivity will get its due visibility and appreciation.   

This practice leverages a key benefit of story sizing, i.e., speed. Comparing your new stories to a reference and then bucketing them is a quicker process because you don’t reinvent the wheel of what a 1-pointer is with each new set. You could change these reference stories as needed, so long as you are diligent that they match the original sizes. 

Display the reference stories prominently in the team area on a wall. Make it a habit to carry out estimation around that wall. This will also work well while onboarding new members into the team’s estimation exercise. All they will need to do is understand those reference stories and their sizes well enough to start contributing immediately and productively to estimation. 

With reference stories, you will put into place a sure-fire method to eliminate errors in sizing and to maintain the relativity of the stories in your backlog. By displaying them such that they are the focus of every estimation exercise, you will establish a best practice to avoid this antipattern.

Time-based estimates are a bad idea

Time-based estimation is frequently used in software development projects, even though it is far from being accurate or efficient. Here’s a deep dive into the inherent problems that should prompt both developers and managers to avoid this approach.

Continue reading “Time-based estimates are a bad idea”

Dining Tables

In this episode we discuss the “dining table” seating arrangement for XP teams. We’ve covered several advantages of this way of sitting. We have also talked about a few disadvantages and some ways to counter them.

Have you had good / bad experiences working in this kind of a setup? Share them in the comments… Are you looking to try this kind of a setup in your workspace but not quite convinced? Share your concerns / doubts…