In this series of posts, I’ll be addressing the misconception that it’s not possible to plan releases using agile methodologies. In a previous post, I talked about the three sides of the “Iron Triangle” that can be adjusted when project milestones start slipping. In this post, I’ll talk about planning releases for a Scrum team where scope is flexible.
Why Flex Scope?
A team might choose to be flexible on scope when they are making releases on a regular schedule, or if requirements need to be implemented by a hard date. In this situation, because the release date is set, if milestones are slipping, the product owner will need to make decisions on which features must be in the release and which can be postponed for a later release. Let’s talk about how the business can make plans around which features are likely to make it in a release and which won’t.
Planning in this way assumes two things. First, it assumes that you have a well-groomed and prioritized product backlog. Second, it assumes that the team has been sprinting long enough to have a fairly predictable velocity. If these prerequisites are not met, this method of planning will not be particularly accurate. This inaccuracy isn’t a symptom of trying to plan for an agile methodology, though. Planning without those prerequisites would be similar to trying to plan a waterfall project without having good requirements and without knowing your resource availability.
Best and Worst Case Scenarios
With this kind of planning, the team must first decide on a best and worst case velocity. This can usually be done informally because these values will be refined as sprints are completed.
Let’s imagine a team has an average velocity of 40 story points. After some discussion, the team decides that if a sprint goes horribly; if everything that can go wrong does, then they would likely get a velocity of about 25 points. Then the team talks about an amazing sprint. One where the Scrum gods smile upon them and absolutely everything goes right. They decide that if that were to happen, they might have a velocity of around 55 points.
The team then uses these numbers to determine a range of points they can complete by the release date. In this example, let’s assume the release is to happen after six sprints. The team calculates the number of points they should be able to complete for the best case and for the worst case.
Worst case points: 25 * 6 = 150
Best case points: 55 * 6 = 330
The team then draws lines on their backlog at those values. All the stories above the worst case line will definitely be ready by the release date; even if everything goes wrong in every sprint, the team will still complete those stories. All the stories below the best case line will definitely not be done by the release date; even if everything goes perfectly in every sprint, the team cannot get to these stories. The stories between the two lines are maybes; the team may or may not complete them depending on what happens during those sprints. At the beginning of the six sprints, the team can’t be more precise that this; they will continue to refine the estimate as they sprint, though.
After each sprint, the team will recalculate the best and worst case lines based on how many sprints are left. For example, after three sprints, with three sprints remaining, the worst case will be 75 points (25 * 3) and the best case will be 165 (55 * 3). The team then redraws the lines for the backlog items that have yet to be completed. As the release approaches, the number of stories the team knows they will complete will increase. Similarly, the number of stories the team knows they will not complete will also increase while the unknown section will shrink. This will allow the product owner to be more and more confident about what will and will not be in the release as the development progresses.
Planning With the Customer
As the scope estimates are refined, the product owner, working with the customer can determine if the stories are still prioritized correctly. Sometimes there are features the customer feels must be in the release, but after a handful of sprints it becomes apparent that they will likely not meet the cut. When this happens, the customer can start working with the product owner to re-prioritize as soon as this is discovered.
Take it to the Next Level…
Some people may feel uncomfortable with the team just deciding what their best and worst case velocities should be by using the old “wet finger in the wind” method. If this seems a little unscientific, it is possible to add some rigor if you have historical data on the team’s velocity. If this is the case, you can calculate the mean and standard deviation for the velocity over a period you feel comfortable with and use these values to come up with minimum and maximum velocities with given confidence levels.
By taking this data-driven approach, it is now possible to produce scope estimates that also include a general confidence level in that estimate based on historical data and typical variation in velocity.
Hopefully this has gotten you thinking about the kinds of information you can share with your project stakeholders for schedule-driven efforts. I’ll demonstrate a similar technique for scope-driven planning soon.
A common misconception about Scrum is that teams using it can’t do planning. In the next few posts, I’ll be demonstrating some techniques that can be used to plan releases for teams using Scrum.
In a previous post, I talked about the options project teams have when a project starts to fail. In it, I described the three sides of the “Iron Triangle” that can be adjusted when things start slipping. In this post, I’ll talk about choosing to flex the cost side of the triangle.
What does flexing cost mean?
Being willing to flex on cost can mean several things. It could be buying some additional tooling, buying new hardware, or setting up new environments. Those are all things that might help get a project back on task. However, when most people talk about being flexible on cost what they often mean is adding additional resources, and that is something that rarely helps get a failing software development project back on track.
Other folks have covered that topic much better than I can, so I won’t go into all the gritty details. A good place to start is the book “The Mythical Man Month” by Frederick P. Brooks Jr, but there is a wealth of information available on the internet dedicated to this topic.
Why do people do this? What are we hoping to improve by adding resources to a Scrum group? One word: velocity.
Why doesn’t this work?
Velocity is a tricky beast. At its simplest, velocity is a measure of how much work a Scrum team can complete during a single sprint. While the concept of velocity is simple, understanding how it is affected by changes to a team is anything but. In general, adding new people to a Scrum team tends to initially disrupt the ability of the team to get work done.
From a purely technical perspective, the usefulness of adding resources to tasks relies on that work being parallelizable. In other words, the work can be broken up into pieces that have no dependencies on each other and can be consolidated into a whole after the pieces are all complete. Unfortunately, most software development tasks don’t fall into this category, and adding additional resources only adds to confusion and communication problems.
Ignoring technical issues, the people and personality challenges caused by adding “new fish to the pond” can also prevent velocity from immediately improving. These kinds of factors are also very hard to mitigate and usually just need to run their course.
Can additional cost ever help?
While adding more resources to a Scrum team in the hopes to have an immediate positive impact on velocity doesn’t tend to work, there are ways to increase the team’s velocity in the long run.
Adding members can eventually increase a team’s velocity. If the need for more capacity is recognized early, adding new members to the group will increase the velocity after the group has had the time to reintegrate. How long that takes varies from group to group. These additions to the group would ideally be new permanent members of the team, not simply burst capacity brought in to push schedule to the left. There is also a “sweet spot” for team size. If the team grows past about nine people, it may be wise to split the group into more than one Scrum team.
If team members are not fully allocated to the Scrum team, increasing the existing team members’ allocation will absolutely allow them to get more done each Sprint. My preference would be for folks to be 100% dedicated to their Scrum team, but I also live in the real world and understand that that doesn’t always happen. If your Scrum team members aren’t 100%, making them full time is the best way to increase their capacity for work.
So how does this help with planning?
It doesn’t, much. Since it’s really not possible to know what effect adding team members will have on velocity, you can’t really plan accordingly. Bummer.
Given my druthers, on projects I’m working on, I’d much rather be flexible on schedule or scope than on cost. I’ll talk about those in future posts.
In project management, people often talk about the triple constraints, or the “Iron Triangle”. It describes the concept that when a project encounters obstacles there are a limited number of things that can be adjusted; the schedule can be slipped, the scope can be decreased or money can be spent to purchase additional resources or tooling. There aren’t a lot of options outside those three, but sometimes a project sponsor is unwilling to bend any of the edges of the triangle. What happens then?
People who have been involved in more than a few projects understand that unforeseen things will happen. When a project sponsor is unwilling to be flexible on schedule, scope or cost the team often goes into hero mode in order to bring the project back on track. The unfortunate truth is that this rarely works. As people start putting in longer hours they get tired and start making mistakes. This typically has the effect of putting the project even further behind.
In reality, when we’re not willing to bend one of the three sides of the iron triangle, we are actually bending the hidden fourth edge: quality. People will start advocating decisions to cut corners. Testing often gets thrown out the window in the interest of saving time. In the end, quality suffers, and in many cases the project misses its schedule, scope or cost goals anyway.
My recommendation for every project you work on is to have the project sponsor decide which of the constraints they are willing to let bend when difficulties arise. I also recommend that instead of including just schedule, scope and cost in the list of options, that quality is also one of the choices. Most people are not willing to sign their name to slipping quality when the project starts failing. Furthermore, explicitly listing it as an option will drive home the reality that that’s what will suffer if one of the other options isn’t chosen.
In the next few posts, I’ll talk about different techniques that can be used to plan Scrum projects once we’ve chosen which edge of the triangle we’re willing to flex.
I’ve been working on an Agile (Scrum) transformation at my company for about a year now. I knew that most of the developers here were ready for a little more structure around how code is written, tested and delivered. I expected the team members to be fairly welcoming, but for some reason, I’d planned on the users and stakeholders being somewhat resistant to the change. I’m not really sure why I felt that way; I likely didn’t think about it as much as I should have.
It turns out I was completely wrong.
Part of our plan was to take small steps in our roll-out of Scrum across development teams and make sure that we are able to demonstrate benefits before moving on. My hope was that as developers, users and customers had positive experiences, the word would start getting out. It turns out that it’s working just as I’d planned, and as I’m starting to hear the buzz in the back-channels, the biggest accolades are coming from users.
The biggest change they say they’re experiencing is with the level of involvement and ownership they’re feeling. The users love the fact that they can understand the user stories that are being written. They like being able to help set acceptance criteria to make sure what is being delivered is what they need to get their jobs done. Project owners and stakeholders like the fact that requirements are being broken down into smaller components than they’re used to. This is helping them understand what is being built and how much work is really involved in delivering each feature.
They’re enjoying transparency.
I had planned on meeting with users and stakeholders who would be impacted by our Scrum teams at some nebulous point in the future. It seems that I need to rethink that idea, and start going out into the user community much sooner. Like tomorrow. Time to get some training time scheduled!
One of the most important things I’ve learned as I’ve been working through the Agile transformation at IDT is that not everything is going to go as smoothly as I would have liked it to. I have to remember that I’m introducing (sometimes very significant) changes to how people do their job, and it’s not unreasonable for people to have some resistance to that.
Forcing change on people or saying, “you will do this simply because I say so” is not a winning strategy. I remember days I would head home feeling defeated and beat down. It’s important not to give up. Keep as positive an outlook as you can, and plan your strategy for the next discussion. Don’t keep repeating the same tired arguments over and over. If they didn’t convince someone before, that person is not likely to suddenly change his or her mind about it. Try to understand where people are coming from and what their concerns are. Find ways to address their concerns. If you can’t, it might not be a bad idea to question your approach. Above all, challenge issues and not people.
In future posts, I’ll cover some ways to help overcome objections to agile and dispel some pernicious agile myths.
Most importantly, keep a positive attitude and don’t give up!
I’ll be speaking at the Iowa Code Camp at The Kirkwood Hotel in Cedar Rapids, IA on May 9th. I’ll be giving my “Selling Scrum to your Organization” talk. Please drop by and chat! I’d love to speak with you!
If your team uses user stories to define requirements, I highly recommend making sure you keep the user at the center of the stories. Let’s say a user comes to you and says, “We need to enhance the system to make sure we send certain key customers gifts on their birthday.”
Developers are technical folks, and it’s natural for them to immediately start thinking about how they’re going to implement this new feature. Because of this, their first instinct is often to write what I call a developer story rather than a user story. It will likely sound something like this:
As a developer
I need to add the field DateOfBirth to the customer table
so the system can know to send them a birthday gift
The problem with this is that when you work with the user to validate the story and gather acceptance criteria, these technical stories often cause them to disengage and feel they can’t contribute. If instead, stories are written from the viewpoint of the user, they’ll be much more likely to feel ownership and provide more useful feedback.
Given the birthday gift requirement above, a better user story might be.
As a customer service employee
I need to be able to record a customer's date of birth
so I can ensure we send them a gift for their birthday.
As a customer service employee
I want to receive a notification two weeks before a key customer's birthday
so I can ensure I have time to write a personal card for them.
As a developer
I need to create a notification service
in order to get notifications to customer service employees.
Of course, there are always exceptions. Sometimes a user story really is for the developer, but these cases are typically reserved for internal team or infrastructure stories. If the story is that the developers want a framework to start using ATDD, for example, writing that story from the standpoint of the developer is absolutely natural. In this case, the developers are the users receiving the benefits of the work.
Give it a shot. Your users and stakeholders will thank you.