Timebox Development - PowerPoint PPT Presentation

Timebox Development

Mike O’Dell

Based on an earlier presentation by

Bill Farrior, UTA, modified by Mike O’Dell

FUNCTIONALITY

DEADLINE

CSE 4317

• A Rapid Application Development (RAD) technique that:
• focuses on schedule
• imposes a fixed time limit of a project
• focuses on critical requirements
• forbids (further) scope creep
• does NOT work for all types of projects
• very large projects
• projects in core business area(s)
• is often deployed with other RAD techniques, such as Evolutionary Prototyping, CASE, SWAT and JAD

CSE 4317

• Things don’t always go as planned
• Scope changes
• Estimates were in accurate
• People
• Timebox Development provides a way to redefine the product to fit the schedule
• Schedule is the priority
• Avoids the “90% complete” problem
• Controls product definition

CSE 4317

• First used at DuPont
• Scott Shultz
• Documented by James Martin
• “...Better to have a system of limited functionality working quickly than to wait two years for a comprehensive system.”
• The application must be built so that it can be added to quickly

The two year wait...

CSE 4317

• Users/developers keep adding  design slow to converge
• By placing a rigid limit on delivery, developers are less inclined to experiment
• Excessive functionality in software and electronic products often goes beyond usefulness

Enough,

already!

CSE 4317

• Implementation/construction phase practice
• Implement essential features first, then other features as (if) time permits
• The product “grows like an onion” with the essential features at the core
• Prototype and evolve approach
• Requires heavy end-user/sponsor involvement
• Usually last 60-120 days

CSE 4317

Product

Rejected

Timebox Development

Build &

Evolve

Prototype

System

Definition/

Priorities

Evaluate/

Deliver

System

Prototype

Request for

Change

End-user

Review &

Feedback

Review Board

Need for large-

scale change or

enhancement

CSE 4317

• Signs off on system definition (priorities) prior to timebox
• Monitors progress
• Evaluates completed system
• YES / NO decision on completion.
• Decision made quickly on each stage
• Includes:
• executive owner
• user representative(s)
• QA professional

CSE 4317

• Clearly prioritized list of features
• What’s essential and what’s not
• Minimum core feature set
• Realistic schedule estimate
• Right kind of project
• Ability for extremely rapid turn-around on prototypes (Evolutionary Prototyping?)
• Sufficient end user involvement
• Quick feedback is essential (JAD?)

CSE 4317

• Interfaces among subsystems determined, and held constant
• Complex projects broken down into very small projects, which proceed in parallel

TIME 

CSE 4317

• Extraordinary productivity improvements with Timeboxing on certain projects
• 80 function points per PM with Timeboxing vs. 15-25 without
• No projects rejected with Timeboxing
• Risk lowered/eliminated in many projects

CSE 4317

Speed

Quick feedback on basic functionality

Smaller teams reduce communication overhead

Problem tasks become visible

Can be used to save a doomed project

Disadvantages

May be attempted as a last-ditch effort on unsuitable projects

Improperly applied (wrong project or wrong approach), may sacrifice quality instead of features

CSE 4317

• Only use for projects that can be implemented within 60-120 days
• Ensure that all stakeholders agree on minimum core feature set and prioritization of features
• Be sure that team has bought in to aggressive Timebox schedule- and motivated properly to support it.
• Focus on quality throughout the process
• Cut feature if necessary, don’t extend the Timebox deadline

CSE 4317