Scrum and Management: Planning and Focusing

September 23, 2008 — Posted by Al Shalloway

Listen to the podcast Scrum and Management: Planning and Focusing

Over the last several years, teams of developers have been trying Agile and getting success at their level. Now, management is getting engaged, both to figure out how to do this across divisions and the enterprise, as well as how to do a better job in less-than-simple situations that most enterprises face.

There have been notable examples where things did not go as well as expected when teams face complexity, where the fit is not exactly good, where maybe the initial approach taken was just too simplistic. It is management's job to help teams look at ways to improve.

This is why at conferences, we are encountering more and more mid-level managers. And they are asking very different sorts of questions than technical, development teams ask. This is stimulating and exciting. Clearly, Agile is beginning to enter the mainstream as a better way to manage software product development.

In this podcast, we will touch on two topics Alan that are concerns for management: Release Planning and Focus.

Release Planning

For example, one of Alan's talks at SQE focused on User Stories. Now, typically, developers want to know about how to use User Stories to write features and code. Managers, on the other hand, ask questions about how to get User Stories in the first place, how to manage them, how to use them to create more business value.

This is a great question. It comes from the perspective about why we are doing something rather than what we are doing next.
Our approach, which is covered in our Agile Analysis course, uses Minimally Releasable Feature Sets.

Here is an example. Suppose you are embedding graphic presentation of data streams on a web page and your customer is very particular about how the graphics look.

Looking just at features, you might specify a releasable feature is that you provide a histogram, which is a useful type of chart. A second releasable feature might be a pie chart. Another might be choosing colors. And so forth.
Each of these features might involve many stories.

The question is what is the minimum set of releasable features required before giving it to the customer? From a technical standpoint, you might want to have them all done first. It feels less risky, technically, and may make for a greater initial splash in the market. But what if, instead, you provided a basic histogram that let the customer validate the entire data collection and display process and the rough placement on the web page? And, with that basic system, they could begin showing it to early adopters in the marketplace and thus begin to establish market penetration?

Which option provides the most business value? How would you feel if you targeted release of all of the features in 6 months only to find that your competition promised to release half of the features in 3 months with the rest of the features in another 3 months. Would that put you at a competitive disadvantage?

There might be good arguments for various alternatives. The point is that as a product development team, you need to have the conversation and not make assumptions. The outcome of your conversation will be the minimum set of features required for a release. And then you can still talk about how you will package the features into the final release to the customer.

This bringing the business perspective to Agile release planning is a needed corrective to what many Scrum teams do. Too often, they dive right into stories and then try to coordinate with Epics and Themes. This local team approach is, perhaps, too narrow of a perspective; it cannot address the portfolio of products that the business needs to be working on.  

Iteration Planning

Now, it is different when it comes to planning an iteration. Now that you have specified the minimum set of features that will go into the release, you are not constrained to work on one feature and then another. You are not required to work according to adding business value iteration by iteration (remember, business value comes with releases, not with iterations). Instead, you select work from across the set of features, doing whatever is required for the team (or teams) to make progress toward the release goal. Your selection criteria is based on other sorts of factors, such as:

  • maximizing feedback
  • mitigating risk through architecture
  • mitigating risk of teams working together
  • minimizing contention for resources

This is consistent with the Lean notion of "optimize the whole."

The Right Focus

One of our customers is a defense contractor, making missile systems. In one of my classes, I asked the students what their responsibility was. One bright student piped up, "we are responsible for making missiles perform reliably. They need to launch when they are supposed to launch and not launch when they are not supposed to. They are supposed to follow the proper flight plan to the right target and then go off when they are supposed to go off. That is our responsibility."

Exactly right!

As software developers, we are responsible for the larger picture. Writing software is part of what we do to fulfill that responsibility.

Naive implementations of Scrum attempt to protect teams from management. This is sad because too often, teams quickly end up focusing on local issues. One of management's jobs is to help teams figure out where best to focus. The proper and more powerful uses of Scrum is when management and teams are working together. 


Training by Net Objectives


Music used in this podcast by Kevin McLeod at

For more information, contact or visit us at

Blog Type: 
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban