The next step in the evolution of Agile project management

09 Sep, 2010

In this blog, I make a case for what I think is the next step in the evolution of Agile project management. The focus of project management used to be based on managing Tasks that people perform to deliver a piece of software. Agile project management shifted focus to managing the delivery of Features. I believe that the time is ripe for the Agile community to take the next step: move towards Value driven project management.

Task driven Project Management
In waterfall projects, project management effort is geared towards delivering a predefined set of features within predefined time and budget constraints. During a project, project management effort is focused on managing the Tasks that are identified to deliver these features. It is hard to predict exactly which tasks are needed, how long they will take and how they depend on each other. The result is that projects are often delivered over time and over budget.

Feature driven Project Management
In Agile projects, project management effort is mostly focused on features. An Agile project may target a fixed release date and have a fixed budget, but the exact set of features that is delivered will be refined along the way. Managing the tasks to implement these features is left to the people that perform them. The effort of a Product Owner is focused on prioritizing and refining features that the Agile teams will work on.
This approach has proven to be much more effective in delivering software within time and budgetary constraints. However, the ultimate goal of software development should not be to deliver features within time and budget.

Value driven Project Management
Teams build features that add Value to the business. Examples of business objectives are “increase market share”, or “increase customer satisfaction”. Underlying such high level goals, there usually are lower level goals such as “increase the number of visitors to our website”, or “increase the percentage of visitors that buy a product”.
Currently, most people on Agile projects have a good understanding of the cost of features, but not of the Value that is delivered by these features. What do you think is more interesting to know about a software release:

  • “A sum of 400 story points worth of features has been delivered”, or
  • “The SEO optimization in the release resulted in a 30% increase in the number of visitors to our website, which resulted in an increase of market share by 5%”?

To plan for Value, business objectives should be expressed explicitly, they should be quantified and they should be measured. For the features we build, we should be explicit in how and to what extent we expect them to achieve these business objectives. Using measured data after releasing new or improved features, it should be validated whether they have the expected results.
For a team to be effective in helping to achieve business objectives, it is essential to have a shared understanding of them. Only then the knowledge and creativity of people that work on a project can be used to come up with the best ways to achieve them. Only then can it be validated which features are really adding most value to the stakeholders.
Note that the idea of Value driven project management is not at all new. Agile pioneer Tom Gilb is preaching this ever since he pioneered doing iterative software development. Together with his son Kai they are on an endless quest to convince the world that this is the way to do project management if you want to be competitive.
I think the Agile community will catch up with them eventually. In the evolution of project management, moving from Task driven to Value driven just proved to be too big a step. The current Feature driven approach is a necessary intermediate step. To be competitive, you should want to be in the forefront. It’s time to take the next step. It’s time for Value driven project management!

Newest Most Voted
Inline Feedbacks
View all comments
12 years ago

It is a good thing, but I don’t know why you are linking it to “Agile” project management so specifically. As you mentioned the Evo guys have always done it, it also seems to be a lean thing. But lumping every good thing under the Agile banner isn’t really good for those things, nor for Agile, it just dilutes it.
So sure, one of the next steps in managing software development, for sure. But I don’t really see where the focus on Agile comes from in this article.
It is like seeing an upswing in component-orientation, or functional programming or something, and calling it a next step in agile software development, when really it is just a next step in software development, independent of agile. Nothing fundamentally agile about it.
Or have the agile alliance or someone recently made some changes to their bylaws or something that I don’t know about?


[…] this article, I found this blog post via twitter – also pointing at value driven project management as the next step in the […]

Alireza Haghighatkhah
12 years ago

Nice post, thanks for sharing, as you mentioned in this post we are moving to family of new project management methodology which are based on value from our customer point of view, agile methodologies are here in order to fill the gap and most of ideas are derived from lean management methodology.

Lars Vonk
12 years ago

Hi marco,
How is this a next step? Agile has never been about delivering features, it has always been about delivering business value.
As you know this comes back in scrum for instance where the product backlog is prioritized on business value and where you constantly check if the product increment that you delivered still meets the business needs or that it needs adjustment.

Machiel Groeneveld
12 years ago

I totally agree with the goodness of a value-driven approach. One thing to notice is that this makes the team’s job a lot more complex (not a bad thing) and most people will need training/time to understand how to create value in stead of (just) the features.

Lars Vonk
12 years ago

Hi marco,
Why even start a project if you have no goals? That’s just a potential big waste.
But on having goals etc we have no disagreement. And also the gilb method of quanitying stuff is valuable in some cases, and hard as machiel mentioned.
I am just saying by claiming it as the next step, you are implying it is something new in agile. But if IMHO people didn’t focus on business value before they completely missed the point agile was/is trying to make.


[…] Mulder writes about the difference between task driven, feature driven, and value driven project management, in the context of Agile […]

Tom Gilb
12 years ago

Lars and others may be missing a subtle point here. Conventional agile practice assumes that value can be described by stories, use cases functions and burn down charts for value delivery progress.
Our (Evo, Value Delivery Method) assumption is that these are weak and failure-prone ideas. That you must identify several key values, you must quantify them with defined scales of measure, and required levels of value. That is a key difference. It might interest you to know that Jeff Sutherland and other key agile people entirely agree that this quantified value approach is a necessary front end to Scrum/Agile practice.
For more detail see many papers and slides downloads at and here is a recent one in addition:
What’s Wrong with Requirements Methods?
and my papers on on Agile Principles
and soon to be published agile values

Ben Linders
12 years ago

Talking in Scrum terms, I think it’s not the responsibility of the Team to define and measure value. It is the Product Owner who should know, and quantify, the value. As mentioned earlier, this is essential information for prioritizing the backlog, which is a responsibility of the Product Owner. However, when the expected value of a user story is know, then the Team can easily report how much value has been delivered in an increment.
This is not to say that Team should not understand the business value, they should as much as possible. But it’s the Product Owner skills and knowledge, and his/her collaboration with the Team that is essential to show how much business value has been delivered.
BTW: The best way to learning how to define, quantify and measure value is by starting to do it, and improve along the way (sounds agile, doesn’t it?).

12 years ago

One of the main goals of any business is to be competitive. And you have very rightly mentioned – “For a team to be effective in helping to achieve business objectives, it is essential to have a shared understanding of them. Only then the knowledge and creativity of people that work on a project can be used to come up with the best ways to achieve them”. The importance of shared understanding of the business objectives is a key input that helps the team to make clever trade offs in various low level implementation decisions.

Erik Gibson
Erik Gibson
12 years ago

Great post, Marco. Missed you at Agile2010!

Radu Davidescu
12 years ago

It’s nice to focus on value. It can lead you directly to succes. The only problem is that is far more difficult to predict a value rather than effort. Value it’s a lot more unpredictable than effort. It’s a less precise model, I’m not saying that is a wrong one! As long as you take into consideration this huge possible error rate. When you estimate value, you can be wrong a lot more than you think, or sometimes just under-estimate a value of a piece of code. Of course, mixing this model with Agile provide quick feedback and that is a good point to retrospect value added (as prediction it’s something a bit foggy)
best regards,

12 years ago

Let me try out this new concept.
So first; high level business goal:
In order to gain an increased market share on Agile training courses by 5% and to increase the number of attendees to our training courses in NL by 15% in 2011, we as a company (and as Agile trainer) want a training course about Agile Planning and Estimation, irt Business Objectives and Requirements Management & the Role of Product Owner and (other) Business People created en marketed.
Second; Lower level business goal: In order to delight potential attendees and our marketers, create a training and develop appropriate marketing material for agile planning, estimation, business objectives irt requirements management & the very important role of Product Owner and (other) Business people training, by the end of November 2010, so it can start from January 2011.
Third; Prioritized backlog looks somewhat like this:
1. Determine what audience to address… (before august 2010)
2. Get attention to the need of envisioning, planning, estimating en prioritizing… (end of august 2010)
3. Think of an appealing name… (beginning of September 2010)
3.a: send a preliminary notice to potential attendees (September 20th)
4. Determine content of training course… (halfway November 2010)
5. Make training material…(end of November 2010)
6. Invite a guru to co present / determine who is trainer… (end of November 2010)
7. Decide on date, location, fees, price etc… (ultimate date December 5, 2010)
8. Offer training course… (December, 6, 2010)
9. Execute training…(before end of January 2011, bi-monthly)
1, 2 and 3 are in sprint 1
According to DoD: 1, 2 are ‘done’. The above post being a part of backlog item nr. 2.
For nr. 3 some tasks are in progress:
One of them being Sprint Item: 1D1. Choose between suggested names like:
New Agile Master class Estimating, in short: “NAME”
Agile University of Training & Coaches Headquarters, in short “AUTCH”
Science Based Agile Guru Series: “From Feature to Value” (No acronym available)
Certified Requirements and Agile Planning (No acronym available)
I think I am too much of a newbie at project management and product ownership with somewhat more affinity with non-software development. Perhaps I need to attend this training myself…
It is absolutely special that you bring this as the next step in Agile. This means either that you believe that all previous Agile projects have “just” started without anyone seeing the value of it, in spite of existing business case, project brief, executed kick-off session, JRP meeting, etc. or that Agile ensures that software is ‘just’ built even though there is no underlying business value or it’s not well understood.
It’s quite remarkable that this is brought as new thing, something that is much older than Agile, scrum or any contemporary method/ paradigm. What you are trying to get across is probably even older than Lean (including 6 Sigma) and you position father and son Gilb as apparent “expert happy few” to it.
I think you have some colleagues with all the skills that you attribute to these ‘gurus’. And what about yourself? Cruijf once said: ” “Je gaat het pas zien als je het door hebt”: You will only see it when you get it”.

Cesario Ramos
Cesario Ramos
12 years ago

Hi Marco,
Nice post!
Seems like you are proposing to adopt more wisdom from the Lean movement 😉
The most important Lean principles being Customer Value and the Value Stream.
Totally agree that it’s important for people to really understand what Value is for the business and even better value for the customer, so that they can start removing non value adding activities and use their talent in reaching the business goals.

ron leunis
ron leunis
11 years ago

I really do not understand this post…
Tasks driven vs feature driven vs value driven project management…
It is not versus it’s: a waterfall of business drive which generates tasks to produce features.
Tasks and features should only be in the project if they add business value…And it should always be managed with the anticipated business value in mind. Tasks and features do not mean anything without the business value they should add to.
The product owner has defined the business value already. Otherwise it should not be on the list as a task or feature to be developed. And it should be tested and checked for the business value during the sprints and the project.
In the good old days using the waterfall method, it started with defining the business value as a starting point.
I am surprised to see in the agile community this is now suddenly regarded as a big insight..And the next evolvement in Agile P.M.
There should not be an agile project if it does not add business value. And if there is business value to add, the project to create it, should have always been managed and tested with the business value in mind.
Business requirements which add value: that has always been the driving factor to start a development project. And the only base to manage them. Tasks to create features without the business requirements (to add value) should not have a reason to be started.
This thread is probably just an effort to try to make people aware again that methodology (agile) is just a a way to reach the real goal (adding business value).
The old “What” versus “When” against which “Cost”. The “How” is using a methodology which balances these 3 in producing faster and cheaper more meaningful applications. Which add business value.
A development methodology only has a reason to exist when it can make the development of the “What” more efficient in time, cost and easier to maintain once live.
Was not that the reason to start using “Agile”?

Explore related posts