[QUESTION] What Do Managers Control on an Agile Project?

The number one question that I get from managers who are learning about Scrum and Agile is: What do I control on an Agile Project?

Flight Controls - Bryan Burke - Flickr

Flight Controls – Bryan Burke – Flickr

It seems like a simple question to answer, but if you go the purist route and deep dive in to your self-managing teams talk, you risk alienating the manager. After a few failed attempts at answering this question, I think I’ve found a better way to address this very real management concern.

This question usually comes up when I start talking about how agile teams are self-organizing and self-managing. Managers like the prioritized backlogs and the value tracking. Those things can be turned in to forecasts and metrics that map to their past experiences.

Self-organization feels odd to them, but they seem to get it. Self-managing teams on the other hand can lead to this kind of reaction:

“Wait, if teams self-manage, then…what do I control?”

Doubling down on self-management theory has not worked for me in the past. I’ve also tried answering this question by pointing out moments during a sprint where a manager can help the scrum team inspect and adapt their practices and the increment of software, with mixed results. And honestly, this answer is begging for more trouble than it’s worth.

During my most recent encounter with this question I gave a different answer.

A manager on an agile project controls empowerment, which drives how much and how fast value is delivered to an organization.

Every design review meeting, status report, security assessment, dashboard, metric, and inquiry take time (capacity) away from the team. This is time that could be used to get a valuable feature to a “done” state and ready to be shipped at the end of the sprint. In other words, attempting to control the project delays value from being delivered.

The impacts of trying to control an agile project can even be quantified if needed. I like to add the mechanisms that managers use – additional status reports, design reviews, and excessive documentation – to the team’s definition of done.

This creates transparency with the product owner and ensures that the scrum team takes these activities in to account when estimating their work. Future sprints can be run without the overhead of the control mechanisms to determine any differences in velocity.

Honestly, these managers have never had control of their software development projects – regardless of the methodology used. At best they had an illusion of control. Project are made up of people, not status reports. You can try to convince, coerce, inspire, or lead, but in the end people are going to do things that you cannot predict. And there isn’t a metric, meeting, or dashboard that can change that fact.

Question: How would you handle this question? I’d love to hear your take on it. You can leave a comment by clicking here.



phgaillard2001 | le depart | flickr

phgaillard2001 | le depart | flickr












Scrum Master is a Title, Servant Leadership is a Mindset


Unknown | Team | Flickr

Unknown | Team | Flickr


  1. What is a servant leader?

What is a servant leader?












But things did – and tend to – work out.




[QUESTION] The Product Owner Says #NoEstimates From the Team. Now what?

What would you do if your Scrum Product Owner decided that customer value should be the sole focus of the scrum team and therefore wants to eliminate estimation (#NoEstimates) from the scrum development team’s process?

Kerrin Asmundson | Free Estimates | Flickr

Kerrin Asmundson | Free Estimates | Flickr

Perhaps the scrum product owner read the exchange between Neil Killick and me and decided that #NoEstimates is the way to go. Is it possible that I failed to express the benefits that estimates can bring?


But in this case, the answer is pretty simple. As a scrum master I would remind the scrum product owner that he/she does not have control over the team’s practices or their estimates. There is a misconception in some organizations that a product owner is a “manager”.

This simply isn’t true.

The scrum product owner is responsible for optimizing the value of the scrum development team does. This is primarily achieved by providing a well refined and prioritized product backlog.

Scrum teams are self-managing and own their processes. The team is responsible for continually inspecting their practices and results – usually in a sprint retrospective – looking for continuous improvement.

Following that explanation, I would then ask the team what they think about the scrum product owner’s request.

Scrum is a “developer play” after all. So it only makes sense to ask the team what value they see in estimating (or not estimating) their work.

If after such a discussion, the team decided to go the #NoEstimates route, I would fully support them.

There are some topics that the team would need to speak to with capacity being one of them. Forecasting for the product owner would be another. As long as the team as figures out how to meet these business expectations, then why not give #NoEstimates a shot? Scrum is based on empiricism. Inspect and adapt!

In this example, the scrum product owner decided that estimates are overhead. This sentiment is hard to disagree with. Estimates are pretty worthless. They expire quickly. When requirements change they expire even faster. Worse of all, estimates are almost always wrong.

But that is why scrum teams estimate often. We are not trying to hit a date or measure the accuracy of our estimates. Rather, scrum teams uses estimates to guide them on how much work they can complete in a sprint.

The estimates can also be used by the team to discover their sustainable pace and to forecast a few sprints out to see where stories (features) could be delivered. These activities have value to a scrum team and to the product owner during release planning activities.

But these benefits diminish if the estimates are not continually updated. During these multiple planning poker (estimation) sessions, the team learns quite a lot about the story in question and about each other. These interactions can lead to a much better team and product.

As a scrum master you should be looking for opportunities to empower your team to make their own decisions. In this case, the scrum product owner wanted to dictate how the team estimates (or doesn’t estimate) their work. Instead, the better approach is ask the team to discuss the idea and decide for themselves whether or not to give it a try.

Question: Have you ever taken an idea to the team that you may not have agreed with? What did the team decide? Did you support the decision? You can leave a comment by clicking here.

[QUESTION] Why Do Scrum Teams Estimate in Story Points Instead of Hours?

Management wants to know how long it will take to get something done. The problem is that people are terrible at estimating features in hours. Why? Because it is hard work, inaccurate, and not a lot of fun. Scrum teams have a better way – story point estimation.

Steve Dalton | Poker Planning | Flickr

Steve Dalton | Poker Planning | Flickr

Hours or duration is complex to estimate on software projects. Teams and individuals are expected to figure out how many hours a particular user story will take to implement – before doing any actual work. It’s not surprising that 60% of software projects fail at this task.

Hours have a different meaning to different people. Developers have varied skillsets, abilities, competencies, domain knowledge, and experiences. Given a diverse development team, a consensus on how many hours a user story will take to finish will be extremely difficult to reach.

For example, let’s take two developers – Senior and Junior. They have been asked to estimate USER STORY X. Senior, who has many years of experience, thinks that USER STORY X will take 5 hours to complete. Junior, who just graduated from college and is working at his first job, and thinks that it will take 10 hours to complete the story. There is no way to reconcile these estimates and reach consensus.

Even if the hours could be reconciled, the meaning behind the hour estimates are unclear. Is that 5 hour estimate expressed in ideal time or elapsed time? In other words, is that 5 hours of work assuming no interruptions, distractions, and other commitments? OR is that 5 hour estimate really 20 hours in duration because the work was spread over 3 days due to meetings, disruptions, or other life events?

Instead, scrum teams use story points – a unit of measure for the size of a user story. The actual values and units are not as important as the value of the stories relative to one another. A story that is a 10 should be twice the size of a story that is a 5. The estimate is also all inclusive. Everything that is need to get the user story completed is considered in the process.

In our case, Senior and Junior can decide that USER STORY X represents 1 story point. They could then look at other user stories on the product backlog and decide the story point value of the remaining user stories based on their relative size to USER STORY X.

This abstraction removes the complexity of estimating in hours and simplifies the estimate to a relative sizing exercise. Mike Cohn put it best in his excellent book Agile Estimation and Planning:  “A story-point estimate is an amalgamation [consolidation] of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherit in it, and so on.”

Hours based estimating is popular, but it is also more complex. It is also frequently wrong. There are many variables that are out of your control that you end up having to factor in (more guessing) or ignore (bad guessing).

Estimating is waste. Customers do not pay for estimates. You can’t claim ROI from an estimate. Scrum teams do not deliver estimates at the end of every sprint, they deliver working software. Estimates have no intrinsic value. So why invest a lot of time on them?

Since scrum teams know that they are going to be “wrong” when estimating, they use story point estimation to quickly and inexpensively size their user stories. As they inspect and adapt their work during and after each sprint, they can revisit their estimates and adjust as needed.