7

I am researching agile methodologies for my organization. My question is this:

How do you prevent a project from running for far too long while using agile?

You can be writing requirements while feeding into a product backlog, the dev team can run with a sprint backlog while other requirements are being fulfilled.

What is to keep a growing requirements list from extending a project for far too long? How do you set that initial boundary so you can determine if the project has gone too far?

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
dbobrowski
  • 271
  • 1
  • 4
  • I tried to clean up your question a bit, but was stumped about the purpose of your second paragraph. Could you clarify how writing requirements and processing the sprint backlog fit into your question about initial project duration? – Todd A. Jacobs Jan 18 '13 at 17:52
  • 1
    The current title of the question and the question itself are two completely different topics. – Andrew Clear Jan 18 '13 at 19:46

3 Answers3

3

Three things: time-boxing, a prioritized backlog, and involvement of the product owner in the form of consistent feedback.

Prioritized Backlog

Keeping a prioritized backlog ensures that the most important user story is implemented in the next sprint. In this way, the team is constantly creating a minimally viable product. Keeping a prioritized backlog is essential to managing scope creep. With a properly managed backlog scope creep is essentially impossible. Unimportant user stories will remain at the bottom of the backlog, no matter how many ridiculous user stories they want to throw at you.

Consistent Feedback

Consistent feedback from the stakeholder/product owner is essential. This will allow you to gain better understanding of what they actually want, which is rarely what they initially say they wanted. Be careful though, feedback must be prioritized along with the rest of the backlog

Time-boxing

Using an iterative cadence is naturally time-boxed. Since your team is continually creating a viable product, this feeds directly into your product schedule. The product should be deployable at the end of each iteration, therefore you can choose to cease development at the end of any iteration, and have still created a product of value.

The important thing to ensure is that the team is implementing the project in functional units during iterations. In this way there is no "too long". There is merely the current state of the working project.

Andrew Clear
  • 2,380
  • 15
  • 20
2

TL; DR

Initial duration is defined by estimating the initial Product Backlog. Like all projects, this duration can vary over time based on scope and velocity, and needs to be constantly updated and re-assessed. Termination by the Product Owner is the explicit control for preventing undesirable scope creep or infinite schedule slippage.

Project Goals Are Defined By Stakeholders

The Product Owner is responsible for working with stakeholders to identify project goals. Generally, this involves devising themes and epics, and then filtering them using some sort of consensus-building framework.

Some common tools for building and prioritizing the initial Product Backlog include:

The tools aren't what's important, though. It's really about defining an initial scope so that the schedule can be estimated.

Initial Product Backlog is Estimated by the Scrum Team

Once the initial Product Backlog has been defined, the Product Owner takes it to the rest of the Scrum Team, along with any shipping dates or project milestones defined by the stakeholders. The Team then estimates as much of the Product Backlog as they can within the planning time-box, and works with the Product Owner to identify what epics are likely to fit within the planned schedule.

Note that this is a cooperative endeavor. The Product Owner provides scope and optional deadlines, and the rest of the Scrum Team provides the Product Owner with enough feedback about the Product Backlog to give the stakeholders an initial project schedule.

Project Termination

The project ends whenever any of the following happen:

  1. The Product Owner terminates the project because it delivered sufficient value.
  2. The Product Owner terminates the project because its goals will not be achieved.
  3. The Product Owner terminates the project because stakeholders have withdrawn funding or shifted organizational priorities to other projects.
  4. The Product Backlog is emptied, and no new stories will be added.

Scrum projects expect change requests and scope creep, so they generally require an explicit termination. This may or may not coincide with the original scheduling estimate, but termination by the Product Owner is the explicit control for preventing undesirable scope creep or infinite schedule slippage.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
1

I think the best way is to pander to the priorities of the project decision makers when reporting progress.

  • When project decision makers are cost-conscious try running Agile projects on a time & materials basis. That way the decision makers are presented with an estimated dollar cost for the next sprint and can decide if the perceived benefits of the new functionality being delivered in that sprint is worth the cost.
  • When project decision makers are time-conscious you likely won't have the problem of the project lasting "too long". Still, you may want to try to forecast remaining duration of the project based e.g. on the estimated units worth of work remaining as compared to capacity and contrast this to the relative value of what will be delivered.
  • When project decision makers are scope-conscious there may be reduced value in doing Agile approaches in the first place. Part of the premise of Agile is that you are delivering high-value functionality first, with the corollary that you could de-scope in order to save time and money.
Doug B
  • 8,899
  • 17
  • 40