Turn The Ship Around – Intent Based Leadership

David Marquet was about to become a submarine commander. He spent a year learning everything about the boat he was going to command. Two weeks before he was to assume command he was given a different sub, and the only thing he knew was that it has the reputation for being the worst in the Navy. He made it the best. Here’s how.

Thanks to Peter Green for sharing this video with me in his Certified Agile Leadership workshop.

Posted in agile | Leave a comment

Don’t Finish Your Epics! Deliver More Value Instead.


Product team is starting to assign business values to epics so we can, along with effort estimates, set correct priorities. However, we also have quarterly goals. Once we reach the end of a quarter, if an epic is not completely done (all stories under it), how do we get partial credit?


I recommend rolling the value down from the epics into the stories themselves. This way, you can see what you delivered in the quarter. Keep in mind that value estimates, just like effort estimates, are really just a tool to help with planning and decision making. At the end of the quarter, I’d like to see you focusing on the awesome stuff you delivered and what your customers’ reactions were to that new functionality.

I also recommend not trying to complete all of the stories in the epic. That type of ‘completion thinking’ is often a holdover from the old way of thinking: “We must do all of the things that we said we would do.” It’s not usually the best approach. When a big epic is broken into smaller stories, it’s not the case that all of the stories are equally valuable. Some are very valuable, many are fairly valuable, and some are nice to have but not really all that valuable. Deliver the most valuable stuff, and then keep an eye out for when the rate of value delivery is falling off. At that point, there is usually other, more valuable stuff that the team could be working on. So you should have the team stop working on the current epic, and move on to the other more valuable stuff. Free yourselves from ‘completion thinking’ and focus on constantly delivering value at the fastest possible rate.



Posted in agile | Leave a comment

Smaller User Stories Podcast

I recently had a conversation with Dave, over at the Mastering Business Analysis podcast, about splitting big user stories down into smaller stories. The interview was a lot of fun and it’s available now. You can get it direct from the Mastering Business Analysis website, or point your podcatcher at one of these links:

You can also read about splitting user stories at SmallerStories.com.


Chris Sims

Posted in agile, scrum, software | Leave a comment

What Is The Role Of Project Manager In Scrum?

This question came from a client: What is the project manager’s role in scrum?

In answer to your question about project managers, there is no project manager role in scrum. The duties of a project manager gets split between the product owner, scrum master and the development team.

The product owner has the vision of the product and is the business representative accountable for making sure the business is kept up to date about the product, the schedule, and the budget. The product owner does this in multiple ways including:

  • Grooming and refining the product backlog
  • Understanding the development team’s velocity so he/she has a sense of when backlog items may be ready for release
  • Communicating frequently with the stakeholders
  • In the sprint review meeting, helping the team demonstrate new features and facilitating conversations with the stakeholders on the direction of the product and the product backlog
  • Sharing and maintaining a budget

The scrum master is responsible for coaching the development team, protecting the team from changes during the sprint, training the team in scrum, helping them overcome obstacles, coaching and supporting the product owner, facilitating scrum ceremonies (meetings like the retrospective). The scrum master is truly a servant leader. They also are the agile champion for the whole organization. They would work with executives and other departments to have scrum work. For example – as a scrum master I would work to coordinate the work between scrum teams and non scrum teams if needed.

The development team takes work into a sprint and then they themselves decide who does what and when they do it. They have a daily scrum everyday to update each other on status and plan the day – so there is no need for a project manager to hand out tasks or manage people to make sure they are working.

So what I ask project managers when they are switching to scrum is – Where do you find your passion? Is it in working with business, developing a product vision and getting that product to market, managing the status, deciding which work should be done, spending a lot of time with stakeholders getting their opinions and buy in?

Or do you love spending time with the development team, having them win, solving problems or removing obstacles, helping people work better together, being an agile champion, training and coaching, creating retrospectives, being more in the weeds of how the development team works without being their manager or telling them what to do. Helping the development team to be self organizing.

This usually gives project managers a good direction of which scrum role they would be best suited for. It’s best that people choose where they want to provide value rather than assigning them to one role or another. I always ask project managers – Where do you think you could create the most value? That is everyone’s job in scrum, to create value anywhere they can.

Hope this was helpful.

Warm regards,

Posted in agile, project management, scrum | 2 Comments

Creating Scrum Teams – Choosing Who Is On What Team


How should we form scrum teams as our organization adopts scrum?


Deciding how to form teams, and which people should be on which teams is the work of management. Of course there are many ways management might choose to do this. One of the most effective ways I’ve found to figure out roles in a scrum transition is to let people decide for themselves! This may sound shocking (who let’s employees or even worse contractors decide what role they will fill), but we’ve seen it work very well. The operative word is transformation. The power in scrum comes from its focus on self-organizing teams producing value rather than individuals doing work.

Start with some good training for everyone so people have a shared understanding of what scrum is, what the roles on the team are, and how adopting scrum will help the organization create more value and a happier healthier work environment. I’ll shamelessly recommend Agile Learning Labs’ Certified Scrum Master workshop for this step. :-) .

Next we assure everyone that they will still have a job and their salary. This might seem like not a big deal – but think about it. The roles in scrum aren’t a 1 for 1 match with traditional project structures. Maybe it’s good to say that again. The roles in scrum are not a 1 for 1 match to traditional project structures. That’s the point – if this doesn’t get addressed what often happens is that roles stay the same with new titles and no real transformation takes place.

So after everyone is assured they still have a job and a salary, we can talk about what roles will be needed on the scrum teams. Each team will need a product owner, scrum master, and three to nine development team members.

Product owners are concerned with the product and it’s how it’s doing in the market.

Scrum masters are most concerned about the people and helping the people work together more effectively.

The development team consists of the people who actually create the product. This might include coders, testers, documentation specialists, or people who have whatever skills are needed to create your products. Developers are concerned with what’s getting built – the quality and building the right thing, the technology.

So I ask people what their primary concern is? What get’s them out of bed? Is it guiding the product? Is it guiding people and teams? Or is it building the product? It’s usually fairly obvious to them.

Finally – I ask them to organize themselves into teams of roughly 5-9 that can produce value (potentially shippable product) based on where they see themselves.

I tell them that each one of them has a main job of figuring out where they can produce value and that as a whole group we need to make sure that all the teams can produce value. Then I let them go. It’s a bit chaotic for sure – as people form teams and deal with making adjustments so that each team can produce value. The teams choose or request scrum masters from the folks who have self-selected into that role.

Often teams form in much more organic and productive ways than if management had assigned people to teams. This is management putting its money where their mouth is when they talk about the power of self-organization. It sets the stage for people on the teams being accountable for producing value and being valued by the business for their contribution.

It can be a bit nerve racking to do it this way – maybe like jumping into a cold lake or jumping out of a perfectly good airplane – I think you’ll be happy if you go for it.

Posted in agile, scrum, teams | Leave a comment

When Can We Start Sprint 1?

Screenshot 2016-09-07 13.43.11


How long should we time box the prep time before the first sprint starts – i.e. the time used to decide on a product that has a good chance of meeting the goals, make effort and business value estimates and get the top product backlog items to be sprint ready?


I would look for the shortest time you can to prep. To get started in a sprint you need a team and a product backlog. You don’t need a complete and perfect product backlog – since more product backlog items will get added as you go along and existing items will be altered and sometimes removed. I would start working and refining the backlog as you go – so you don’t end up with a “design sprint” that takes longer than a sprint itself.

The Scrum Guide outlines that up to about 10% of the development teams capacity will be used in backlog refinement activities. These activities are ongoing and collaborative between the product owner and the development team. The scrum team decides how and when refinement is done. In the initial sprints, that activity might look like several backlog refinement meetings to get the backlog to a state where there are 2-3 weeks of sprint ready product backlog items. After that it may look like one refinement meeting per week and the development team members doing research, prototyping, etc. to get information to refine the product backlog items.

I would start with the vision, have some product backlog items prioritized in the product backlog and do a few product backlog refinement sessions to get them sprint ready. They don’t have to be perfect – smaller is better. The question to ask in the session – is what’s the smallest piece that could be delivered to get feedback that is still a deliverable? For the product backlog items farther down in the backlog – they can be big, with a swag estimate and a general idea. Then as they are moving up – they need to be split, have new acceptance criteria and estimated.

Sprint ready product backlog items are items that can reasonably be “done” in a sprint according to The Scrum Guide. For the best chance of this I find it useful for sprint ready product backlog items to have four components:
1. They are small enough to be completed in a sprint
2. They have agreed upon acceptance criteria
3. They have an estimate
4. They have no outstanding dependencies

Mostly, the idea is to get the shortest feedback cycle possible in a way that works for your teams so the scrum team can begin seeing real product and getting feedback from stakeholders to make sure they are on the right track.

Warm regards,


Posted in agile, scrum | Leave a comment

Scrum Retrospectives With Cathy Simpson

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.

Posted in agile, coaching, project management, scrum, teams, videos | Leave a comment

Estimating Tasks and Management’s Role in Scrum

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!



Posted in agile, scrum, teams | Leave a comment

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



Posted in agile | 1 Comment