TODO: INTRO PARAGRAPH

When you have an existing software product, with an existing a team in place you are often prioritizing maintenance costs against capital investment costs. Maintenance costs go towards keeping (maintaining) existing clients, while the capital investment is often critical to securing new business and new opportunities.

This can be a very tricky balancing act. On one side, the maintenance costs can be seen as going towards a bridge to keep existing customers on your application, platform, or technology. On the other side, you might have a new product or technology that opens you up to entirely new markets, users, and clients.

  • The backlog is used to define scope for each sprint.
  • Overall backlog is the set of requests. It does not yet represent a commitment, it is just a record
  • Rejecting or prioritizing items low is essentially the same thing.
  • Low priority items that persist for long periods of time need to be re-examined, and groomed off the list or re-evaluated to understand why the items have persisted for so long. For example, are there missing information or details that would alter the priority?
  • Only high priority items on the backlog are detailed (estimated, broken down, stories written, etc.). In other words, do not spend effort estimating work for items that are not prioritized high.

Structure

Many organizations have structure in place to approve work over a certain threshold. Work grouped into a set of tasks with a definitive start and end is typically called a project.

  • PMO
  • Council
  • Governance Committee + Steering Committee + Working Committee

Process

  • The project team needs to approve the prioritization of the next sprint worth of backlog. This is usually achieved by providing direction, then reviewing the outcome of applying that direction to the top of the backlog.
  • What has completed? Are we progressing? Is the project stalled with no progression, or is it taking on more scope?
  • Typically the estimates to accomplish the scope are proven incorrect, usually more dependencies are discovered. Actual additional functionality is easier to spot and curb.
  • The work we chose for an upcoming sprint, aligns with business goals, and can be scrutinized at each sprint planning session. Generally the scope is estimated to be what is containable within the sprint.
  • Each 2-week sprint the team has new information, and can update their estimate (burnup chart), perhaps uncovering that the planned work is no longer feasible (cost is higher than benefit)
  • The progress boards must be reviewed during prioritization meetings or review discussions.
  • In order to properly estimate work, there is often dark matter that needs to be explored. In order to address this, meaningful discovery work (often in the form of a PoC) needs to be included in the backlog. Information from the PoC is used to propose some initial steps to solving the customers problems. Some solution is usually better than none.
  • The work to improve the solution continues until other priorities take precedent. (Adjustments made at the sprint boundaries).
  • Attempting to make the decision up front either rejects outright any solution, or commits to a specific solution before all the required information is known.

References