Organizing at Scale: A Basic Scrum Framework for Enterprise Teams

Recently, I was working with a smaller, but distributed, team that was trying to establish a basic framework for working together in a lightweight, Big Picture, enterprise pattern. We were rolling out a basic scrum practice for the individual teams, but one that lends itself to scaling well into enterprise release planning, and is also based on sharing and communicating sprint objectives, rather than just a prioritized backlog . (After all, what team or stakeholder wants to sort through another teams backlog just to understand what they are doing in a sprint?).

Based on a little background with the team, I assumed we were all working from the same playbook. Well surprise, surprise, there were many misunderstandings about the basic practices I thought we had standardized. That led to a variety of interesting conversations.  To clarify intent, I put this brief framework together and thought perhaps others might be able to use it as well.

One caveat though, while this is what I use to good effect, I make no claims that it would be a perfect fit in any other “Scrum team in the enterprise” context. Your mileage will vary, but here you go:

Sprint Pattern

Sprints are two weeks in length. Sprints for all teams start and stop at approximately the same day. Each sprint has a standard pattern. Plan the Sprint. Execute the Sprint. Demo the Sprint. Retrospective.

Plan the Sprint

1)   Presentation of objectives and stories by the product owner.

2)   Breakout. Team members work independently or in collaboration to understand intent and draft an acceptance test for each story. Teams use task/hour breakdown, or not, at their discretion.

3)   Commitment. Teams reconvene and commit to negotiated objectives and supporting stories for the Sprint. Commitments are made only by the team. Final objectives are stated in a sentence or two, in plain English, and are communicated to all stakeholders.

Execute the Sprint

Teams collaborate on achieving the objectives of the Sprint. Stories are discussed, elaborated, completed and demo’d to the product owner as available. Story (not task) status is maintained in “big visible chart”. Typical story states Backlog, Defined, In Progress, Complete, Accepted).
However, the objectives for the Sprint trump any particular story. Team (but not management) may refactor, add, or delete stories where necessary to achieve the Sprint objectives.

Demo the Sprint

Results of the Sprints for each team are demo’d to all team-aligned stakeholders. In the larger enterprise, an additional, aggregate, higher-level demo or “Feature Progress Review” may be necessary for program stakeholders.

Retrospective

Team conducts a short retrospective in two parts:

Objective (metrics) Review: Determine whether or not the team met the objectives of the sprint (yes or no). Collect any metrics team has agreed to, but teams must understand velocity, both for new development and that devoted to maintenance.

Subjective (process) Review. A typical format is: What Went Well? What Didn’t? What One Thing Will We Do Better Next Time?

Typical Sprint Ceremonies

In a two-week sprint, a typical meeting (ceremony) set is as follows:

Standard meeting set

Release Cadence

Releases (or Potentially Shippable Release Increments) are at approximately 90 day intervals (approximately 6-7 sprints per Release Increment). Teams may include stabilization (hardening sprints) or not based on quality, system level integrations, continuous integration capability and technical debt issues.

Release Planning

Release planning occurs at the beginning of every 90-day cycle. Release planning is typically one or two days, face to face wherever possible. All team members participate. A standard format is as follows:

• Review and retrospective on accomplishments of prior release.
• Executives communicate current business context
• Management presents solution Vision, including a prioritized list of features
• Teams break feature into stories, plan the Sprints based on known velocities, negotiate commitments with stakeholders.
• Teams identify risks and impediments. Each is discussed and addressed into categories as follows: (Resolved, Owned, Accepted, Mitigated.
• Teams (including management) restate (in plain language) team and aggregate objectives for Release, so that all stakeholders understand all objectives
• All present commit to release objectives, or planning continues until a commitment can be achieved.

Release Planning Output

The output is a set of clear objectives, along with a prioritized feature list, for the upcoming release increment.