Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News Should We Manage Both Features and Tasks?

Should We Manage Both Features and Tasks?


A key element of any Agile process is the "input queue" - variously called "product backlog" in Scrum, "story cards" in Extreme Programming and "feature list" in Feature-Driven Development. It seems easy enough, right? What could be simpler than making a wish-list? But it's not quite so simple, and in fact it's critically important to manage the quality of this queue, and to have a regular cycle for managing it. Failure to do so can result in uneven flow of work, delivery of misunderstood features, half-finished work, or micro-management. All of these dysfunctions reduce the effectiveness gains that Agile teams typically experience.

New teams trying to turn an existing project plan into a feature list immediately run into a problem: the list must be filled with customer-valued features, and the project plan is full of technical tasks like: complete requirements, upgrade to Oracle 10i, implement webservices framework, integration testing.  These activities have been, until now, invisible to the customer - and herein lies the "transparency" shift inherent in Agile. Technical tasks are always needed - but Agile teams must justify working on them in terms of a customer-valued feature. So, the first time a feature is requested which must pass through the webservices layer, the team will explain to the customer that the cost of developing this feature requires {list of technical work here}, and the customer must agree to spend their cash on these activities before they can be undertaken.

This has a couple of effects:

  • developers must learn to explain their work in terms of customer value - developers learn to understand the customer's point of view
  • customers will understand that they are paying for more than just "that button on the webpage" - customers learn to respect the effort and skill of developers
  • if the customer doesn't feel the cost is justified, they and the team can sometimes brainstorm a "lite" version that is more suitable, so the team can spend their effort on more valuable features.
  • customers and developers are now aligned toward exactly the same goal - customer value. Alignment reduces friction and enables effectiveness.

The feature list is, in fact, a customer-owned artifact, and so should not be filled with technical tasks which, in isolation, produce no customer-valued working software. Management of Agile projects is focused on this feature list, and tasks generally remain the domain of the team itself, as they self-organize to do the work.

Tasks always do need to be done - they are how the value gets delivered. But if a team is working well together, management generally knows not to interrupt and leave them to it, and if the team is not working well together, Agile leaders coach the team to identify and resolve their own problems, always with the goal of increasing value produced. An Agile leader who would mandate or even track team-level tasks would typically be seen as micromanaging.

Jon Kern, one of the 17 creators of the Agile Manifesto, and reputedly "a fanatic about ensuring software development efforts deliver business value," blogged last week on Just what is a feature?

This spurred David Anderson, author of Agile Management for Software Engineering, to talk about his view that sometimes it actually is worthwhile to manage technical tasks as features in Manage Value Creation not Effort Expended. His entry used ideas from the Theory of Constraints to back the unusual position that some kinds of tasks are worth managing.

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • is this gonna really work?

    by Alex Popescu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Deb, I don't think this will really work out:

    # developers must learn to explain their work in terms of customer value - developers learn to understand the customer's point of view
    # customers will understand that they are paying for more than just "that button on the webpage" - customers learn to respect the effort and skill of developers

    because of two reasons:
    1. when two companies are involved there are a lot of chances that not both are "agile". Moreover, in a lot of occasions, the people that would be needed for this process are coming from completely different levels, and so they have completely different views, available time and interest on doing it.
    2. I really think there are people out there that will feel completely unpleasant to find out first "how is pizza cooked, before serving it". Imagine you go into a resto and while trying to get a pizza you get a long explanation about how and what is needed to prepare the pizza. And this is a simple example, because all of us can understand how a pizza is prepared :-).


    .w( the_mindstorm )p.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.