One of the biggest challenges teams have when adopting Agile is the idea of estimating work. When you are used to estimating everything in hours, it is difficult to start estimating work in terms of points or relative sizing. It takes time to adjust to this new way of estimating work. The urge to spend a lot of time getting into every detail of a piece of work before committing to an estimate is sometimes hard to resist. The more estimating a team does, the less team members will think in terms of time and the more they will think in terms of points. The key is to understand why Agile uses points and to understand what goes into determining the points on a User Story.

Real-Life Stories

Story 1: Estimation Overkill

The idea of using relative sizing to estimate User Stories is something I’ve seen work pretty well. The idea of creating a “golden story” and then measuring other stories against it can work really well. But this takes a certain level of comfort with not knowing all the details of a User Story.

While on a Scrum team I saw how difficult this can be. This particular team wanted to have an extremely high level of confidence in the estimates. Even though they thought they were a Scrum team, the five-hour marathon meetings we had talking about User Stories to just get an estimate said we were far from Scrum. After hours and hours of talking about all the “what if” dependencies and possible implementations, I didn’t find that our estimates were any better than if we just did relative sizing.

Thoughts

For organizations that are used to giving estimates in units of time (typically hours), it is hard to adjust to using story points. Further, for teams that are used to getting very detailed in order to get a “level of effort,” it is hard to accept that you can’t predict everything.

As I mentioned, the estimates in Story 1 took about a week to come up with and I’m not convinced that the estimates were better than using relative sizing. I’ve seen on other teams where we did relative sizing and over time we got better and better at estimating. That is why I like the concept of two rounds of estimating in Scrum. The first estimate occurs when the stories are put into the Product Backlog. The second estimate, or re-estimate, occurs during the Sprint Planning meeting when the team learns more about the User Story. In Scrum it is important to always keep three things in mind when estimating a User Story: risk, complexity, and effort. I’ve found that keeping these things in mind when going through the estimation process, and having a golden User Story, helps to keep estimates consistent.

I think it takes time for an Agile team to become comfortable with the idea that you don’t need to know every detail when first estimating a story. You obviously need to understand enough to estimate it, but not every little detail and not to the level of designing solutions. Again, you’ll have another chance to estimate the story before committing to it for a Sprint. In the end, I think the amount of User Stories that go up in number of points and those that go down in number of points ends up being a wash over the long run.

Story 2: Who Estimated This?

One of the things I’ve enjoyed while being on Agile teams is the idea that the team gets to estimate the work. This is only fair seeing that team members are the ones who have to do the work. But while on an e-commerce team I saw something that was the exact opposite of a team doing the estimates. This team was in an organization that was adopting Agile software development. Only a few developers had had experience working on Agile teams at other companies. The manager of the team had some experience but hadn’t been using Agile recently.

The manager would work with the business to determine what work would go into a release. The manager would do t-shirt sizing of what the organization was calling User Stories. Then the team was expected to deliver everything that the manager promised. Not surprisingly, the team felt a little upset when the manager overcommitted the team.

For some of the developers like me, who had been on several Agile teams, this seemed very strange and definitely not what you would see on a typical Scrum team. The team should have been doing the estimates, not the manager.

Thoughts

As I mentioned in Story 2, one of the things I like most about working on Agile teams, specifically Scrum teams, is that the team gets to estimate the work. It is only fair that the team doing the work gets a chance to estimate the work. If not, the idea of velocity and letting the team self-organize is not going to work.

The key is to not change the measure of a point over time. It is tempting to change the meaning of a point over time as a team gets better and knows more about the space its members are working in. For example, you may have estimated a story as 3 points and then, when you work on it months later, you may say, “We can do that faster now, so let’s make it 2 points.” But that is dangerous because it is going to skew the velocity of the team. The same is true if you start changing the definition of “done done.” You might be tempted to change the rules for “done done” over time, but again, that can skew the velocity because now the things needed to close a 3-point story are not the same as they used to be. It is important to keep the measure the same over time using a “golden story” and a consistent definition for your “Steps to Doneness.”

Story 3: Excuse for Poor Estimating

One thing that I have seen Agile teams do when writing User Stories is to add a “technical assumptions” section to the story. The team puts all its technical assumptions in this section, things like “logging framework already exists” or “database is already designed.” When the team works on the story during a Sprint and finds that one of the assumptions is not true, it has the opportunity to increase the point value on the story or create a separate story to handle the “unanticipated” work. On one team, though, I saw this lead to poor estimating because the team knew it could use these “technical assumptions” as a way to increase the points on a story later.

Thoughts

Historically I’ve been a proponent of having this “technical assumptions” section on User Stories. I’ve been on several Agile projects where we used such a section with great success. But I’ve come to question this approach after the experience with the team I mentioned in the Story 3.

Is it really just a way for the team to make up for bad estimating or to artificially increase its velocity? When we estimate stories, especially when using t-shirt or relative sizing, we don’t know every little detail, and isn’t the estimate based on effort, complexity, and risk? Without this “technical assumptions” section, if you hit something unexpected while working on a User Story, it becomes blocked and that impediment will need to be removed; this is what I would call the typical workflow for a Scrum team. I think having these “technical assumptions” can lead to poor estimating because the team knows it has a way to change the point value during the Sprint. For me, the jury is still out on this approach, but I would lean toward not using it as part of your estimating process.

Story 4: Another Reason to Use Points

Learning to measure work using story points can be difficult. I’ve been in organizations that are trying to adopt Agile but are stuck in a mentality of measuring work in time. For example, I was on a project where we were supposedly using Scrum, but yet we still measured our work in hours. Instead of having a golden story and thinking about complexity, effort, and risk when estimating a story, we would discuss how many hours the User Story would take a “typical” developer. When discussing how many hours a User Story would take, we would talk about things like unit testing, and so on. In this particular organization we still had Project Managers. Technically there is nothing wrong with that, and they can coexist with Agile. The problem was that when a project started to slip, the Project Managers saw that unit testing was a significant part of the estimate and deemed it “nonessential” for the project. Regardless of whether this particular project was Agile or not, sacrificing unit tests to meet a deadline is usually a short-sighted decision.

Thoughts

There are many things that were wrong with that mentality of cutting unit tests on the project mentioned in Story 4. But for the purposes of this discussion, I will focus on why using story points is a better approach than using hours.

I think if you are using story points it is much harder for project managers to think about cutting quality. If a story is estimated using points, their only option is to remove scope from the User Story or split the User Story into several stories and maybe move some of them to a future phase.

Let’s look at an example. Let’s say you have a User Story with a point value of 5. Then the project starts to slip and the Project Manager wants start shaving time off the project. When a User Story is about functionality and estimated as 5 points, the option to remove time is gone. The only option is to either remove functionality from the User Story or split the User Story into several User Stories. So let’s say they split the User Story into two stories (one story being 2 points and the other story being 3 points). So now the Product Owner decides the 3-point story is more important, so it stays in the Product Backlog. The 2-point story gets moved to an unscheduled application version or something similar depending on your issue tracking system. From an Agile standpoint, this is a much better way to handle change. Instead of sacrificing quality, you shift scope.

Story 4 provides a simple example, but I think it is just one reason why using story points is better than estimating using time. There are many articles and resources that discuss other reasons why story points were introduced in the first place, so I would recommend doing further reading to understand why story points are important.

Story 5: Right Flavor of Agile

While on an e-commerce team at a decent-sized company in the retail industry I saw how picking the right flavor of Agile really matters. This team was in an organization that was just starting to adopt Agile software development. The manager had some experience with Agile and was a CSM.

As we started to adopt the Agile software development methodology, the decision was made that Scrum would be the best fit. However, this decision did not work particularly well because this team was doing mostly Production support and had constant fly-ins (defects and new features). But because the manager had already committed the team to other things in the current release of the application, the team sometimes had to work extra hours to get everything done.

Thoughts

Over time, the various flavors of Agile have evolved. Using the right flavor of Agile to suit your particular needs is important. I’ve seen where people go to Scrum certification training and think that they “must” use Scrum. So, like the team in Story 5, they try to fit their teams into the Scrum model when it might not be the right fit. While on the team in Story 5, I recommended that we shift to using Kanban.

I had also read several articles on how teams at other companies were using Agile on Production support teams, and it was clear that many companies were struggling with how to use Agile in such an environment. I found a really good article about how one company handles this problem (Use of Kanban in the Operations Team at Spotify, by Michael Prokop and Mattias Jansson, which you can find here: http://www.infoq.com/articles/kanban-operations-spotify). The company uses a “goalkeeper” to manage fly-ins and prioritize work. Any person on the team could play the role of “goalkeeper,” and it was not just one person who had this responsibility every Sprint. I was able to convince my manager to try this approach. It definitely helped our team to better handle the fly-in defects. It was clear that using Kanban, combined with the “goalkeeper” approach, was a much better fit for this team than Scrum.