Agile Summary:

The focus of the Agile model is to eliminate waste. Key to success and creating a hyper-productive team with Agile is to eliminate waiting. In the ideal case:

  • Everyone is working in the same room.
  • There is immediate and 7×24 hour access to stakeholders who are empowered to make real-time decisions.
  • Work is organized to minimize or eliminate multi-tasking.
  • Pull from the product backlog what work can be accomplished in the sprint period
  • Document as needed (e.g. regulatory requirements)

If these pre-conditions are not met and sustained, delays will be introduced leading to waste and reduced efficiency of this model. A clear understanding of what is required for success with Agile, and commitment throughout the organization at all levels must be in place before implementing this approach.

Strategy: Deliver value incrementally, right from the beginning of the project.

Fit: Projects with short work cycles, and implementation times, that can be added to or expanded to over time

  • Work periods measured in periods of weeks
  • Expect requirements may change or evolve over time
  • Value can be delivered effectively in sequential parts (process re-engineering may not be a good fit as the entire scope is required to function properly)
  • Manageable schedule
  • Must have empowered decision makers and experts on the team

This short-cycle concept may have partial origins in Boyd’s decision cycle or OODA loop. The construct was originally a theory of achieving success in air-to-air combat, developed out of Boyd’s Energy-Maneuverability theory: The pilot who goes through the OODA cycle in the shortest time prevails because his opponent is caught responding to situations that have already changed.

  • Observe: make use of the best sensors and other intelligence available
  • Orient: put the new observations into a context with the old
  • Decide: select the next action based on the combined observation and other knowledge
  • Act: carry out the selected action, ideally while the competition is still observing your last action.

In the context of project management, this cycle affords frequent examination of the work underway and alignment with the project purpose, with the ability to re-prioritize new work and adapt to change.

It is interesting to note that Jeff Sutherland, co-creator of SCRUM, started his career as an Air Force fighter pilot during the Vietnam war.

Hybrid: Example

  • Developing new collateral material, web site content, or new business development initiative (agile); A holistic planning exercise may need to take place first to assure a clear strategy and integrated campaign.
  • Marketing department organization change with new roles and responsibilities needs to be completed before rolling out (waterfall)

Agile Planning Requirements: That must be in place-same as Waterfall

  • Vision
  • Charter
  • Project Scope Statement
  • Definitions must be clear for all terminology
  • Project lifecycle model
  • Requirements
  • Schedule
  • Team (self-organizing with the right skills)
  • Stakeholder analysis and communication plan
  • Tools selected
  • Project close process

Features, elicited from stakeholders (requirements collection and design thinking) are called User Stories. Example formats

  •  As a (role), I want (feature), so that (benefit)
  •  As a (role), I would like to be able to (action) to achieve (business value)

They are each written on a card, with enough detail to be able to estimate how long it will take to create or implement. In addition, they should be directly actionable (feasible), valuable, testable, and sized to fit the upcoming sprint. The user story concept requires further conversation (business analysis) with stakeholders ideally just before the sprint.

Features (User Stories) vs Requirements:

  • Functions that can be written on one index card or post-it note, that can be organized logically in a group, and prioritized and agreed to by key stakeholders
  • Consider smaller stories to simplify communications and QA.
  • Crystal clear use cases are essential-the role of the Product Owner is critical-ambiguity will introduce significant waste. It is better to quickly reject an ambiguous use-case.
    • Must have one Product Owner taking all the requirements in and assigning a business value (100-1000) highest first.
  • Estimate for all features or work (relative to known task estimates)
  • Categorize features or deliverables by stakeholder (prioritize)
  • Prepare summary schedule (milestones and release plan)
    • Can use Gantt Chart model (MS Project or other tool)

The collection of user stories is called the Product Backlog. Stories are prioritized (Product Owner) and selected to become part of the release backlog, with planning to estimate how much time for each user story and summed to calculate the total amount of work. Estimating in hours in pre-defined standardized buckets is an effective approach. During sprint planning, the release back log can be split into a set of sprints.

Best Practice: Have team members/experts from the team review, improve, and sharpen user stories-make user stories better first.

Sprint Planning:

  • Product Backlog (prioritization by objective, resource availability, organization function)
    • Create top priority (release backlog) backlog from total project backlog (prior to sprint planning)
    • Business analysis of user stories leading to well defined functional requirements can be a leading activity, done in advance of a Sprint, but as a best practice, only by one sprint.
    • Prioritize and add new features or ideas as they emerge
    • Validate solution to business or organization problem
  • Project scope is managed by changes to backlog list (re-prioritizing) for each sprint by appropriate stakeholders), but fixed for a specific sprint
  • Work delivery plan
    • Analyze business impact of implementation of deliverables and consider appropriate change management process. This is an important consideration for both to-be automated processes, and existing manual processes.
    • Communicate potential impact of decision on time, cost, and resource allocation that may emerge based on sequence prioritization.
    • Commitment by each team member required before start.
  • Estimates to build each part (hours)
  • Chose a standard sprint size and use consistently. Two weeks may be short given the need for planning meeting, grooming meeting, retrospective, demonstration, all adding up to a significant percentage of the 10 day cycle.
  • Risk Management
    • New Teams: work on lower risk deliverables in initial sprints to build team confidence (avoid building low-priority features)
    • Experienced Teams: work on most difficult problems first


  • Daily Stand-up  (what done yesterday, planned for today, help, risks, or obstacles)
    • Large visible board (Backlog-In process-Done)
    • Development Team is responsible for creating the increments and delivering a “done” increment
    • As a good practice, balance the tactical three question exercise with a group discussion on how does the team focus their efforts to get the highest priority work done as quickly as practical; alternate days, once-a-week, define the right cadence for each project.
    • Leave 5 minutes at end for questions if there are other stakeholders attending
  • Frequent testing
  • Interaction with stakeholders from multiple functions
  • Deliver value quickly
  • Visibility to time and progress (Backlog Chart)
  • Issues and risk register(s)
  • Must end on time (even if not complete-material for Sprint Review)

A Burndown charts provides visibility of work remaining, and progress trends are clearly evident. The slope or burndown velocity can indicate the estimated completion date for the sprint. Each day the amount of time remaining for each user story is estimated, aggregated, and displayed on the burdown chart.

Sprint Review & Retrospective (lessons learned and adjustments based on feedback)

  • Team voting process with allocated points, or scale of 1 to 5, and pay close attention to negative votes to understand and adjust solution
  • Seed lessons learned with initial comments from Development Team
  • Avoid superficial retrospectives where there is no drill-down into root cause; this may need to take place in a subsequent, small group analysis.