The Atomic Agile Process

The best process is owned by its team, but everyone has to start somewhere. That’s why I drafted this, a template for Atomic Object’s Agile process. It’s designed to be a starting point for our maker teams as they come together to tackle a new project.

There’s a lot left out of the following breakdown, including dev practices (TDD, pairing, CI), design + dev integration and balance, and details on internal team roles. I’ve kept the focus on coordinating what to work on and deliver next in order to achieve a project’s goal.

While our process borrows quite a few things from Scrum, we certainly don’t follow that process strictly.

Roles

Delivery lead

Delivery leads serve as product owners to the team and project managers to key stakeholders. They define “done” for stories in the product backlog, and they’re 100% available to the team of makers for questions and support. They also build consensus with the maker team and stakeholders, coordinate meetings, share progress updates, and facilitate process adjustments.

When tending to the product backlog, a delivery lead will ensure that:

1. We have 4-6 weeks of sprintable work for the team.
2. Important milestones are identified and estimate dependent stories are estimated.
3. The entire maker team understands the product goals and milestones through the lens of the product backlog.

Maker

A maker is anyone assigned to the team that is focused on delivering the work outlined in the product backlog, e.g. developers, designers, and testers. This Agile process is the primary driver for how these folks work, so they get to be ultimately responsible for shaping it.

Key stakeholders

At Atomic Object, these are our clients. They provide business and domain expertise and perspective. They own the product vision and mission and collaborate with a delivery lead and maker team to manage scope, budget, and schedule. They’re likely not available 100% of the time for responding to on-demand questions, making the support of a delivery lead extremely valuable.

Tools

Product backlog

This is a list of prioritized features, chores, and bugs that drive the dev team’s effort to build a complete product.

Sprint

During this two-week repeated period, the dev team focuses on completing a specific set of stories in the product backlog.

Story

A story is a backlog item referencing a feature or enhancement in the product backlog. It’s estimated on a points scale relative to other stories in the product backlog.

A user story is a reference point for the next conversation a team will have on a feature’s journey from inception to shipment. It is not a requirement specification to be handed off with little context.

It’s a good idea to include who needs to do what in the app and why they’re doing it. In addition, reference supporting UX documentation, assets, and relevant details.

Here is the way we define levels (from least to most defined):

• Placeholder: A very high-level feature potentially requiring many design decisions before an accurate estimate can be made
• Defined: Includes enough description and specific implementation options that a dev team can estimate it
• Estimated: A relative estimate has been assigned by the dev team, with next steps or blocking questions identified to achieve sprintability
• Sprintable: Has enough definition to be brought into a sprint planning meeting, broken down into low-level implementation tasks, and implemented without resolving any known blocking questions, stakeholder input, or design decisions

A user story should represent a product change which needs to be accepted by the delivery lead to be considered “done.” The delivery lead acts as a proxy for key stakeholders when taking on this responsibility.

Chores and bugs are peers to stories in the product backlog. A chore is a planned piece of work which the maker team is responsible for accepting. It could include an internal re-tooling, or a bit of time-boxed research into a technical approach or service. Bugs are, well, bugs.

Points estimate

This is an integer estimate representing the complexity and risk to implement and ship a story, relative to other stories in the product backlog.

Points represent cost. They do not represent value. The cost an estimate is attempting to measure is a maker’s time. Therefore, any backlog item which takes more than 0 time to complete should be estimated. This includes chores and bugs.

The only exception to this rule is for emergent work from bugs or unplanned chores which are understood by everyone as issues that need to be dealt with immediately or before the current sprint ends. Those items constitute actual noise and shouldn’t receive an estimate. If the bug or chore is deferred beyond the current sprint, it is now part of your plan and deserves an estimate to make your plan as complete as possible. There is enough uncertainty in software development as it is, so just estimate the bugs.

My favorite scale is 1, 2, 3, 5, 8, 13, 20, 40, 100. No 0, ?, or infinities needed.

Meetings

Sprint review

• Who: Makers, delivery lead, stakeholders
• When: At the end of each sprint

The maker team demos each completed story at the end of each sprint. All team members and stakeholders are encouraged to attend. Feedback is gathered and longer discussions deferred to follow-up backlog grooming sessions.

Retrospective

• Who: Makers, delivery lead
• When: Immediately following the sprint review

Each member of the team shares what they think:

• Went well
• Went poorly
• Should change

Changes to the process are applied during the following sprint.

Sprint planning

• Who: Makers, delivery lead
• When: At the beginning of each sprint, after the retrospective for the previous sprint

To load a sprint schedule:

1. Determine the amount of pair days available in the sprint (account for time off, meetings, etc.).
2. Ask maker team to pull in top-priority stories from backlog.
3. Break down each story into implementation tasks.
4. Estimate tasks in pair days (1/2-pair day increments).
5. Continue until sprint is fully, but not overly, loaded.

A good sprint planning meeting is focused, boring, and quick. Any what or why questions about functionality or UX should have already been discussed with the team in prior grooming sessions.

We often share the plan with stakeholders and avoid adhering to a strict sprint commitment approach.

Backlog grooming

• Who: Delivery lead + makers and/or stakeholders
• When: As needed

The delivery lead is responsible for ensuring the backlog is sufficiently groomed:

• The next 2-3 sprints worth of stories are sprintable.
• Product backlog prioritization reflects short-term, mid-term, and long-term goals and business priorities.
• All scope to meet release milestones is represented in the backlog and estimated.
• All makers understand how to achieve the project’s goals and milestones through the lens of the backlog.

When starting a new project or defining a follow-on milestone, more and longer grooming sessions will likely be necessary.

When grooming the backlog, the delivery lead will draw on help from the maker team and/or stakeholders for the following activities. The delivery lead uses his or her best judgement to determine who, if anyone, is necessary to include in the activity. Suggested potential groups to include are included in parentheses:

• Estimation: Apply relative points estimate to stories (maker team).
• Refinement: Break down existing stories or add additional detail when more information is available and/or design decisions have been made (maker team).
• Brainstorming: Generate multiple ideas for implementing a feature or solving a product/business problem (stakeholders, maker team).
• Synthesis: Gather feedback, perspective, and insight on multiple options directed at reducing them to one option for the product (stakeholders, maker team).
• Review: Present outcome of internal synthesis or refinement of high-impact stories (stakeholders).

Daily standup

• Who: Delivery lead & maker team
• When: Every day

Keep it short. Figure out who’s working or pairing with whom for the day. Decide what you’re all working on. Ask for help if you’re blocked, stuck, or just need it. Don’t solve problems. Just surface them, identify who can help you, and move on.

Sometimes for remote teams, standup over text chat (IRC, Slack) can be more effective than over phone/VOIP.

Closing

This is a starting template for an Agile process, but ultimately, your process should be owned by the maker team and delivery lead, open to change as they see fit to do their best work. High-functioning teams with autonomy over their process are best equipped to respond to changing work environments with agility—and never be held back by the way they work together.