Should Engineers Take Scrum Product Owner Training?

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.



Posted in agile, classes, scrum, teams, training | Leave a comment

Scrum Sprints: How Long Should They Be?

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 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.



Posted in agile | 1 Comment

Agile in Context

“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.

Posted in agile, presentations | Leave a comment

Stabilization Sprints and Velocity

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:



Posted in agile, scrum | Leave a comment

Excuse me – are you sprint ready?

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.

  1. When the team is having g story time, discuss whether the acceptance criteria is clear. If not, then the story is not sprint ready.
  2. 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.
  3. 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.
  4. 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.


Cathy Simpson

Posted in agile, scrum | 2 Comments

Agile Games at Agile Open Southern California

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.

The video was put together by Cliff Rosa of Rosa Media Productions.

Posted in agile, conferences, games, videos | Leave a comment

How Not To Be a Product Owner

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.

Posted in agile, ha ha funny, videos | 2 Comments

Should Management Use Velocity as a Metric?

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.


Chris Sims

Posted in agile, project management, scrum | Leave a comment

A Scrum Master’s Perspective on Story Point Accounting

Recently, I answered a question about how to do the story point accounting when a user story spans multiple sprints. The scrum team had several user stories that were started in sprint one, but completed in sprint two. Since velocity is a measure of the rate at which the team is delivering stories, we found it best to count all the points for a story in the sprint in which it is completed.

Now let’s examine the question from the point of view of a scrum master. A scrum master’s job is to help the team improve and progress toward the goal of becoming a continuously-improving, high-performing, self-organizing, possibly-over-hyphenated scrum team.

The question is being asked because the team members are feeling some pain. They have worked hard on four stories, but only completed one. This doesn’t feel good and they are looking for a way to alleviate the pain. The quick fix is an accounting trick to give the team ‘credit’ for working on, but not delivering, their stories. This only accommodates the team’s dysfunction. A scrum master will want to help the team find and fix the root causes of the pain. In this way they may fix the problem instead of perpetuating it.

Common root causes are:

I’ve already covered what to do if the scrum team’s user stories are too big. In the coming weeks, I will examine several of these root causes and offer ideas as to how a scrum master could help the team and the organization become healthier and more productive.

Perhaps you can think of other root causes that may be at play here. Leave a comment and I’ll do my best to explore and discuss those too!


Chris Sims

Posted in agile, scrum | Leave a comment

Story Point Accounting Across Sprints

I recently received the following question, asking about how to account for the story points of stories that are started in one sprint but completed in a later sprint. There are some interesting things to consider here about the user stories, the scrum team, the product owner and the scrum master. I suspect the answer to this will take multiple articles, much like our recent series on splitting big user stories into smaller user stories. Let’s begin!

The Question

Let’s say you’re doing weekly sprints and this is Week 1. You believe you can accomplish 20 story points in this week, and you have stories A, B, C, and D – each worth 5 points – scheduled for this sprint. So you plan to accomplish:
A – 5
B – 5
C – 5
D – 5

You do about 80% of A, 60% of B, 80% of C, and 100% of D. If you could get partial credit, it would be:
A – 4
B – 3
C – 4
D – 5

But since you can’t count partial credit, your actual count of the points completed is as follows:
A – 0
B – 0
C – 0
D – 5

And your velocity for Week 1 is 5.

Then in Week 2 you again plan to accomplish 20 story points. We’ve done 11/15 of the work on stories A, B, and C, so there should be only 4 story points left of work to do on these. We can accommodate 16 more story points, which are represented by the next stories, E and F at 8 points each. So our accounting could look like this:
A – 1
B – 2
C – 1
E – 8
F – 8

This would give the appropriate estimate for Week 2 but would miss credit for the full story value of A-C. On the other hand, if you keep the full story value of A-C, our plan for Week 2 would look like this:
A – 5
B – 5
C – 5
E – 8
F – 8

And then it looks like you are planning 31 points for a sprint that can only accommodate 20. It seems that somehow you need to keep track separately of how much work you estimate is really left on A-C to properly plan Week 2. So how do you properly account for partially complete stories across sprint boundaries? Is there some way you annotate that on the cards for partially completed stories?

First Level Answer

In this installment, I’ll try to answer the direct question that I was asked: “How do you properly account for partially complete stories across sprint boundaries?” Let’s start by defining some key terms: user story, story point, and velocity.

User Story
A user story is a business deliverable. When a user story is done, there is demonstrably more value present. A user story is something that some of our stakeholders would understand and be interested in.

Story Points
Not all user stories are the same size, in terms of the amount of work that will be required to deliver them. Story points are a relative scale that scrum teams use to estimate how much work each user story will require. A story that has an estimate of 2 story points is believed to be about twice as much work as a one-point story. Story points are estimates; they are not measurements. Since they are estimates, they are made before the work starts and are not adjusted after the work has been completed.

Velocity measures the rate at which the team is delivering stories. That word ‘deliver’ is very important. The business wants to know when it will get the deliverables (user stories) from the team. Velocity is a metric that helps us predict that. If all stories were the same size, in terms of implementation effort, velocity would simply be the average number of stories the team delivers per sprint. Since stories are not all the same size, velocity is the average number of story points worth of stories that the team delivers each sprint. While estimates are guesses, velocity is a measured value. The unit of measurement just happens to be estimated story points.

Velocity is not a measure of how much work the team is doing. Velocity is not a measurement of how long it took to deliver the stories. Velocity is not a measure of how hard the team is working. And velocity is not a measure of the team’s productivity.

OK, we’ve defined some terms and concepts. Let’s get on to answering the question that was asked. If the team finished one story in sprint one, and its estimate was 5 points, then the team demonstrates that one story in their sprint review and records their velocity as 5 story points.

So the now the team moves on to planning sprint two. The question the team needs to answer is which stories do they have full confidence they will deliver by the end of this sprint. Story point estimates and velocity are tools that can help the team make better commitments about how many stories they will deliver. The team should consider more than just the points and velocity, however. They need to look at the specifics of each story the product owner is asking for and decide, as a team, if they have full confidence that they will be able to deliver that story this sprint. You say that the team believes they can complete stories A, B, C, E and F in sprint 2. That’s fine. If the whole team believes that they will deliver those five stories, then they may commit to them.

Let’s assume that the team manages to complete all five stories in sprint two. They have now completed 6 stories in two sprints. The total of all the story points estimated for those stories would be 5 + 5 + 5 + 5 + 8 + 8 = 36 story points. Thus, the team’s velocity is:
36 points / 2 sprints = 18 points per sprint.

If someone asked what the team’s velocity is, we’d say “18 points per sprint.”

This measured velocity can help the team plan for the future. For example, committing to deliver 20 points worth of stories in a sprint is probably too much for the team right now. The team’s velocity also helps the product owner with release planning. They can expect that, on average, the team will deliver 18 points per sprint and so they can forecast how many stories the team will be able to deliver over the next several sprints. After each sprint, the team will recalculate its velocity and the product owner can update the projections.

The tl;dr

In summary, count the story points for a user story in the sprint in which the story is delivered. Do not count partial points for partially completed stories. If the story was started in one sprint and finished in another, that’s fine. Velocity measures delivery, not work, so account for the delivery when it actually happens.

That’s concludes my first-level answer to this question. There is actually a lot more to explore. Stay tuned, as I plan to post a deeper analysis soon. Until then, happy scrumming!


Chris Sims

Posted in agile, scrum | 5 Comments