Our own Cathy Simpson talks about how to do an agile retrospective with your scrum team in this video. The 5-step retrospective agenda she talks about comes from the book Agile Retrospectives: Making Good Teams Great.
Here’s an interesting question that just came in from a local scrum master. It’s about estimating tasks and management’s role in choosing the practices that a scrum team uses.
The team I am working with wants to do an experiment where they will stop estimating task in hours. Their sprint burn down will be then tasks vs. days instead of hours vs. days. The team believes that they will be successful with this and they are also thinking of creating an initial working agreement for this experiment e.g. any task that will be added will not be longer than a day of effort.
I am supporting this but somehow I have failed in explaining and convincing management. They want me to explain the benefits and the purpose of this experiment. They point to scrum books that say tasks should always be estimated in hours and a burn down chart can only be shown using hours. How do I convince management to allow the team to proceed with this experiment?
Your team is on the right track in moving away from task-hour estimates. We used to think that estimating tasks in hours was a useful practice, but over time, we have learned that it causes more harm than benefit.
One of the issues is that we never find all of the tasks during sprint planning. There will always be tasks that get discovered after we begin the work, lots of them! The very best teams I’ve worked with can find about 60% – 70% of the tasks during planning, and those are the best teams.
When we start looking at estimated hours, we get a false sense of certainty and we start making bad decisions based on that. One common bad decision is to do “capacity planning” where we make sure there are “enough hours of work” for everyone on the team. This is a terrible idea! What happens when we discover the tasks that we didn’t know about during planning? If we planned ourselves “full” we are now seriously “behind” just because of our use of task hours and capacity planning.
My only suggestion for your team is to go for even smaller tasks. I generally recommend that tasks should be small enough that they feel like no more than 3 hours of work. I don’t want to know how many hours of work; I just want the binary answer to the question: Does this seem like 3 hours of work or less? If the answer is yes, we are good. If the answer is no, then break it down some more. The reason is that breaking it down helps us better design how we will do the work.
You may also want to explain to your managers that one meta benefit of the experiment is that the team learns that they are free to experiment and improve. That’s really key to scrum: the development team owns how the work gets done. With that ownership, comes empowerment and also responsibility for the outcome. Management doesn’t need to be convinced to let the team try this experiment; management needs to be convinced that it’s the team’s job to continually improve their practices and management’s job is to create an environment where that can happen.
I hope this helps!
I was recently asked if engineers or other members of the scrum team would get value from a Certified Scrum Product Owner workshop.
Our Certified Scrum Product Owner workshops are designed to build knowledge and skill in three main areas:
- How scrum works and how to use it effectively
- How to build shared understanding of the requirements between stakeholders and the development team so that the team builds the right thing
- How to identify and focus the team’s efforts on the most valuable deliverables
These are topics that every member of a high-performing team should be versed in. Having engineers participate in product owner training helps them understand the context within which they do their engineering work, and helps them understand how to interact better with product owners around topics such as the business value of paying down technical dept.
For products that are extremely technical, engineers usually work closely with the product owner in order to define and refine the user stories. If the engineers lack story writing skills, then the resulting ‘stories’ are often little more than a restating of the architecture and technical design. The problem with this is that many of these ‘technical stories’ need to be implemented before there is anything that is meaningful to the stakeholders. Once those engineers have been exposed to the story writing and splitting techniques in our workshop, they are better able to define/refine stories in such a way that they stay pertinent to stakeholders at all times.
I’ll also point out that all scrum masters should take the product owner training, as scrum masters are the scrum experts that provide guidance to the scrum team and the greater organization. Frequently, the scrum master will be called upon to coach the product owners in the various skills needed to be effective in product owner role.
How long should our sprints be? This is a question I am frequently asked by new scrum masters and scrum teams. Here is how it showed up in my in-box recently.
After we participated in Agile Learning Labs’ Certified Scrum Master (CSM) workshop, my colleagues and I have begun practicing scrum very seriously. We chose one week as our sprint length. Some developers feel one-week sprints are too short, since we have a very strong definition of done. Delivering visible work in one week, along with all of the time in scrum meetings, is too stressful. One team member suggested increasing our sprint length to two-weeks. What are your thoughts?
Thanks for the question! The short answer is keep your sprints short; find and fix the sources of the stress you are feeling. All too frequently, when scrum uncovers a problem we seek to change the way we are doing scrum in order to cover the problem back up. Have a look at this post about story point accounting for another example of this tendency. A better response is to address the underlying root-causes of the problem.
For your team, it is unlikely that the underlying problem is that there isn’t enough time in a one-week sprint to get user stories done. More likely, the team is dealing with one or more of the following problems:
Our User Stories are Too Big
If your user stories are too big, then you won’t be able to complete them in a sprint. Luckily, this is a solvable problem. Have a look at SmallerStories.com for techniques that will let you split any user story into small user stories. Practice these techniques, and you will be able to have meaningful user stories just as small as you like. My suggestion is to get the user stories at the top of your product backlog to be small enough that the development team can comfortably finish four to six each week.
Testing Takes Too Long And We Can’t Finish It All In The Sprint
First, make your stories smaller. When I said the team needs to be able to complete four to six stories each week, this includes the testing; dev-done isn’t done.
Next, work to have the development team swarm on completing the stories that are already in progress, instead of letting the coders start new stories. This makes testing, including that boring regression testing, everybody’s job. Yes, I know, developers don’t like testing. This is exactly why I want them responsible for the testing, especially the regression testing. You see, developers often think that the answer to most problems is to write code; in this case they are right! The best way to solve the regression testing problem is to automate those tests. With the regression tests automated, your professional testers are now free to focus more of their time creating acceptance criteria for upcoming stories, so that the whole scrum team will better understand and agree what will be needed to truly complete those stories. This will lead to fewer surprises and disagreements, and more stories done.
Our Meetings Are Inefficient And Take Too Long
This is a common problem, especially for new scrum teams. The fix is to learn how to have focused, efficient meetings. This takes practice. This takes facilitation, by the scrum master and others on the scrum team. When teams decide to make their sprints longer, in the hope that they will then have more time available for ‘the work’ they usually make things worse instead of better. The problem is that longer sprints have more unknowns and thus are harder to plan. It takes more than twice as long to make a plan sufficient for two weeks than it does to make a plan sufficient for one week. Figure out what’s wrong with your meetings (e.g. You keep getting derailed into design discussions), and fix that.
Our Team Is New And Still In The Steep Part Of The Scrum Learning Curve
It’s true that when a team first starts using scrum, they will struggle. It’s new. They are learning how to do scrum, and that’s hard at first. At first, it actually slows us down, as we navigate the learning curve. My experience is that it typically takes three to six sprints before a new team starts to get over that learning curve. Notice that this is sprints, not time; it’s the number of times through the cycle that matters. With one-week sprints, a new team can get through the learning curve in three to six weeks. Choosing two-week sprints will double the amount of time needed to climb up that learning curve.
My advice is to stick with your one-week sprints and fix the problems that scrum is making visible to you.
“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.”
– Charles Darwin
Just about everyone agrees that being “adaptable to change” is important.
At the same time, many people believe that we’re entering an age of acceleration. The models underlying society at every level are being redefined as traditional linear models of change give way to the explosive power of exponential growth. According to computer scientist, inventor and futurist Ray Kurzweil:
“The 21st century will be equivalent to 20,000 years of progress at today’s rate of progress; organizations have to be able to redefine themselves at a faster and faster pace.”
At all levels of engineering, we need a management methodology that is “most adaptable to change.”
Is “Agile” the answer? When we ask people to voice their opinions, doubts emerge around the concept of “agile methodologies.” Is it a new buzzword, yet another management fad or a new paradigm for surviving and thriving in times of rapid change? Or is there something better on the horizon?
Join Cathy Simpson of Agile Learning Labs to explore these questions at the next IEEE Technology and Engineering Management Society meeting on April 2, 2015. In this talk, we will look for the “core of agile” that will endure beyond the fad. We will address agile in context. Everything that is old is new again; and perhaps we will discover together that we’ve been agile all along. We just didn’t have the context to know it.
Here is a question that just showed up in my in-box regarding how to calculate a scrum team’s velocity when they are doing stabilization sprints. This notion of stabilization sprints has become more popular lately, as they are included in SAFe (Scaled Agile Framework).
We do a 2-week stabilization sprint every 4th sprint where we complete regression testing, etc. but don’t take any new stories. Is there a rule of thumb around including a stabilization sprint in the team’s velocity?
The purpose of tracking a scrum team’s velocity is to give stakeholders (and the team) predictability into the rate at which they will complete the planned deliverables (the stories). Velocity is the rate of delivery. The stabilization work doesn’t represent specific deliverables that the stakeholders have asked for; it is simply a cost that you are paying every 4th sprint, because you aren’t really done with the stories during the non-stabilization sprints.
You can reduce this cost by having a more robust definition of done. Look at each thing that gets done during stabilization and ask “How could we do that during each sprint, for each story, so that done really means done?” As you move more work out of stabilization and into your definition of done, your predictability gets better because there are fewer surprises to be discovered during stabilization. The amount of stabilization time that you need goes down, and you can measure the cost savings in terms of reduced time and effort (which is money). By the way, you can learn more about definition of done this Wednesday at the Scrum Professionals MeetUp.
Therefore, my recommendation is to not assign points to the stabilization work.
Here are a couple of other posts related to velocity:
- Should Management Use Velocity as a Metric?
- A Scrum Master’s Perspective on Story Point Accounting
- Story Point Accounting Across Sprints
A common complaint I hear from scrum teams is: we didn’t finish all the stories we committed to deliver in the sprint. While there are many reasons for this – one often-overlooked one is: The user stories were not ready to enter the sprint in the first place. The solution is for the scrum team to decide which stories are sprint ready before the sprint planning meeting even starts.
The sprint ready vote happens during story time (aka the product backlog grooming meeting). Sprint ready means that the team is confident that they can accomplish the story in one sprint. They have:
- Confirmed and agreed on the acceptance criteria
- Estimated the size
- Confirmed all the story’s dependencies are complete
- The story is small enough to be comfortably completed in a sprint (with all surrounding required processes)
I know this sounds amazing, too good to be true, even. Think about how the chances of work being completed in one sprint would increase if all those aspects of story preparation were completed before the team started? I know – mind-blowing!
So how do you get there? A few small changes in story time and sprint planning make this possible.
- When the team is having g story time, discuss whether the acceptance criteria is clear. If not, then the story is not sprint ready.
- When the team estimates the size of the story, make sure they are taking into account all work required to make a story production ready.
- Is the size estimate small enough that the team could complete four to six stories of that size in a week? If not, the story needs to be split into smaller stories and it’s not sprint ready.
- Review any dependencies on the development work. If there are outstanding dependencies– then it’s not sprint ready.
What if a story isn’t sprint ready? The development team and the product owner can discuss what’s needed to get it sprint ready, and then take the appropriate actions. This means that story might be presented in story time more than once, which is fine – remember refinement is part of the process.
When it comes to sprint planning, the product owner can only offer sprint ready stories to the team. They should offer them one at a time until the team says “Enough!” The product owner should not walk into sprint planning with the sprint already loaded with a whole set of stories, as this creates an unhealthy pressure on the team.
That’s it! It’s really pretty simple – however as with most things scrum – not always easy. So try it out. You don’t have much to lose, except maybe those undone stories.
Our very own Laura Powers recently participated in Agile Open Southern California, where she was interviewed by Scott Dunn. Laura talks about the power of games to help executives understand the changes they need to make in order for their organizations to become more agile.
I’m facilitating a certified scrum product owner workshop today. We talked a lot about how to give product requirements guidance to the scrum team. Then I shared this video.
Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working. That’s not what it is at all. Velocity is a measure of the rate at which the team is delivering stories. If the team worked long and hard on 5 stories but delivered none, then their velocity is zero.
Because of this misunderstanding, I find managers who think that it is important for the team to work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Faced with a manager who wants to track velocity as a management metric, a scrum master needs to identify what the manager is trying to measure, and what business decisions they expect to make with that data. The scrum master can then help the manager find more effective ways to get the data they need to make their business decisions. If the manager wants visibility into how healthy the team is, or perhaps how productive they are, we can provide them much better metrics. Trying to use velocity for these purposes won’t work.
Imagine that you are on a team, and your manager wants to see the team’s velocity increase over time. This is very easy to achieve, the team can simply increase their estimates for the user stories. Velocity will climb as high as anyone wants. This won’t correlate to any change in productivity or business performance, and the manager won’t get what they wanted. Worse, the team has just lost visibility and control of their schedule.
Velocity is a great tool for predicting what the team can deliver in the future, so long as the story points aren’t being inflated. If a user story that the team estimates as five story points today is not approximately as much work as five-point stories estimated in the past, then predictability is lost. Everybody loses.
So what is a better management metric? Number of stories delivered. It’s imperfect, as all metrics are, but it is much better than velocity. Measuring the number of stories delivered per sprint will drive a number beneficial behaviors, and gives a manager a better window into the health and productivity of the team. When a story is done, the team has delivered value to the business. This is what the business wants. Think about it. The business exists to create value, not to create busy people. When we measure the number of stories delivered, we are measuring the rate at which the team is delivering value. More stories delivered means more frequent delivery of value.
So what if we game the metric? Remember, that to game velocity the team inflates estimates. To game the number of stories delivered, the team will break their stories down into smaller stories. There are many benefits that come when the team works on smaller stories. Smaller stories are easier to understand and thus easier to implement correctly. Smaller stories will get delivered more frequently, which allows more frequent feedback. The team will get more frequent product feedback from stakeholders, so they can make more timely adjustments to the product. More frequent story completion means the team will update their burn down chart more often, and have much better knowledge and control of their schedule. Smaller stories also mean the variance in the team’s velocity, the natural up-and-down swings, will be smaller. Additionally, the more frequently the team delivers functionality to users, the more frequently they can inspect and adapt their architecture, design and technology choices. I’ve previously written about how to break big user stories into smaller user stories. Might the team go overboard with this? I’ve never seen it. I’ve worked with hundreds of teams and I’ve never once encountered a team who’s on-going problem was that their stories were too small. On the other hand, most of the teams I coach are having problems because their stories are too large.
So measuring number of stories delivered leads to smaller stories, which increases the rate at which the team is delivering value and also speeds up the various feedback loops that keep the team building the right things. Everybody wins.