I’ve participated in and led a LOT of Agile projects. Some have been more Agile than others, and many of you know the pain behind THOSE words. 🤣
If you’re an Agile practitioner, you know that the method by design conforms to the team, so that no two teams practice the exact same flavor of Agile.
But it helps to have a solid starting point: a plan that covers all the bases, that you can run with out of the gate and then modify as your Sprint retrospectives roll in.
Even better if that plan reflects the tools you actually use, which in many large organizations and projects are going to be Jira and Confluence.
This is the intent of the document below. I’ve refined it over many projects at institutions large and small. It NEVER survives more than a few Sprints intact, but then that’s the point, isn’t it?
I hope it serves you well.
Jira & Confluence are complex products! My goal with this article is not to teach you how to configure Atlassian tools, but to articulate a solid starting point for your Agile process. Tweaking your tools is up to you. If you get stuck, leave a comment and I’ll see if I can help.
Agile @Karmaniverous
The purpose of this page is to lay out the rules of the game. This is how we do Agile at Karmaniverous.
We want a perfect fit between our tools and our practices. Jira and Confluence are the tools we use to manage the Agile process. Therefore: how we use Jira & Confluence is how we do Agile.
None of this is set in stone! The Agile process is also subject to the Agile process. Over time, these rules WILL change as we converge to our own best way of doing business. The goal isn’t to follow some arbitrary rule book. It’s to find out what GOOD looks like, and then do that on purpose instead of by accident! See Retrospective below for more info.
Agile in a Nutshell
The Agile Methodology is a recipe for accomplishing something. It can be used to…
- build a product
- manage a business
- operate a factory
… and just about anything else. If something big and complicated needs to be done, Agile can help.
It’s easiest to understand Agile within the context of its opposite: traditional project management. Consider four basic phases of any project:
- CONCEPT: Have an idea.
- DESIGN: Create a design.
- DEVELOP: Build something.
- TEST: Prove that it works.
Making a mistake and then correcting it during the concept phase is WAY less expensive than discovering it and then trying to correct it during the testing phase, when everything has already been built. So traditional project management (a.k.a. Waterfall) places a high premium on taking those phases in order and NOT making any mistakes.
This approach to project management took us from the horse-and-buggy era to assembly lines and skyscrapers and battleships. But right about the time we started to send men to the Moon, this approach started breaking down.
In the real world, as project complexity increases, change becomes inevitable.
Requirements change. New tools emerge, or we learn something about the old ones we didn’t already know. Somebody finds a better approach.
There are a million reasons why a project might have to respond to change, and this becomes more likely as a project grows. So then the question is: what are you going to do about it?
Waterfall project management implements change management procedures. These are cumbersome at best. Agile takes a different approach by asking this question: what would a project look like if change were frequent and expected?
In Waterfall, an iteration happens when something breaks and the team goes back to the drawing board. A Waterfall iteration is an out-of-band activity.
In Agile, the iteration is the fundamental unit of project planning and delivery.
There are as many flavors of Agile as there are teams who practice it. This is by design: a tool should fit its purpose, so an Agile team is encouraged to adapt its approach until everything works. At its heart, Agile addresses these basic activities:
- Identify what needs to be done.
- Figure out what should be done NEXT and by whom.
- Support those people so they can get it all done.
- Maximize the quality of the outcome.
These activities are performed in a cycle… which is itself one of those things that need to be done, and is therefore also subject to iterative improvement. So as requirements or project conditions change, a team’s Agile practice naturally adjusts to accommodate those changes.
In the real world, EVERY project team engages in an iterative practice. The difference between Agile teams and everybody else is that Agile teams do what they do on purpose.
Agile Tools
An Issue in Agile is any work item that needs to be tracked. Early Agile practitioners wrote issues down on sticky notes and tracked their status by moving them across a wallboard. This is still practiced in many places, but it can be a challenge with a virtual team.
Jira
At Karmaniverous, we will begin by tracking Issues using Jira. Jira is a good choice because it integrates with a lot of other tools, which makes it easy to get new Issues into the Backlog from Slack, email, and wherever else makes sense.
Jira manages Issues on tickets. The more information a Jira ticket contains, the more useful it is! So however you organize your piece of the project—spreadsheets, documents, etc.—be sure also to drop links to those things into the relevant Jira ticket as appropriate.
It is better to link to a document than to upload it to the ticket! That way your document remains live, and any changes you make will be accessible from your link.
Confluence
Confluence is a companion product to Jira, and is similar to a wiki: it’s a website where anybody can create & edit pages. Confluence is a great place to develop & maintain requirements documents, design artifacts, and policy documents like this one, because…
-
Everything is searchable and indexed in a single place.
-
It’s easy to attach or link to documents (e.g. Google Sheets) that need to be maintained separately.
-
A requirements page can easily display an up-to-date list of all related Jira tickets.
-
Jira tickets usually back-link automatically to Confluence pages that reference them.
-
Users can hold and resolve relevant discussions in comments right on a Confluence page.
-
It is easy to generate Jira tickets straight from content or comments on a Confluence page.
Slack
Any Slack channel can be attached to a Jira project using the Jira Cloud App for Slack.
If appropriate—say if the channel represents an Epic—then messages reflecting changes to the relevant tickets can be automatically posted in that Slack channel. In any case, simply mentioning an Issue ID from the attached project will link the ticket to the channel. Here’s an example:
Slack users can also click on a message and instantly generate a ticket from it in the Jira backlog!
Jira Issues
Issues in Jira are divided into categories. Each category carries its own Definition of Done.
| Issue Type | Description | Definition of Done |
|---|---|---|
|
A Story is something somebody will MAKE. Most Stories are first be expressed at a high level and then broken down into low-level Stories. High-level Stories usually describe an outcome on an actor in the system. For example: A User can register a new account. Resolving a high-level Story usually means breaking it down into a number of other issues, including lower-level Stories. Low-level Stories usually describe an outcome on the system itself. For example: Add a graph component to visualize a user’s discounts over time. A good low-level Story contains no open business decisions: resolving it means translating it directly into code. A good Story also expresses some validations. How do we know we did a good job? In high-level Stories, these will become integration tests. In low-level Stories, these will become unit tests. Sometimes a new Story will contradict a previous Story. It's okay. Requirements change! |
High-Level Stories
Low-Level Stories
|
|
A Bug is something somebody will FIX. It needs to be fixed because the system's behavior as built does not match the expectations expressed in the related Story. Every bug should be related to a Story! If a Bug doesn't represent the failure of the system to meet the requirements expressed in a specific Story, then it isn't a Bug. It's just undesirable behavior, and should be the subject of a new Story. A Bug can be resolved two ways. These are not mutually exclusive:
|
|
|
A Question is something somebody will DECIDE. Questions are non-trivial by definition. Every issue has a comment thread where questions can be asked and answered. But if answering a question is a task that needs to be assigned, prioritized, and scheduled, create a Question. Every Question should express its own completion criteria. Decomposition is a valid completion criterion! |
|
|
A Task is something somebody will DO. There are two distinctly different scenarios for using Tasks:
A task can also be broken down into other tasks. In this case, each of the child tasks should be a blocker for the parent task. Every Task should express its own completion criteria. Decomposition is a valid completion criterion! |
|
|
An Epic is something somebody will USE. An Epic represents a very high-level grouping of other issues. Other issues should come out of the Backlog and be resolved in a single Sprint. If they can't be, then they should be broken down until they can. Epics endure across several Sprints, and generally represent a project phase with respect to a broad area of functionality. Epics can be organized into a Roadmap expressing the Project's long-term plan. Most Epics are never resolved, because the functionality they represent is always subject to future development. If not, an Epic is resolved when all the issues it contains are either resolved or moved to another Epic. |
|
One Issue Type that is NOT included here is the Subtask. These are a pain to manage in Jira. Instead, use the decomposes into/derives from Issue Link described below to break an Issue down into more manageable parts.
Issue Links
Any Issue can be linked to other Issues. Issue Links provide traceability, for example from low-level Stories to high-level Stories and related Questions. Links can also provide advanced functionality, for example the activation of Tasks in Task Workflows.
Here are the most common issue link types:
| Issue Link | Description |
|---|---|
| blocks / is blocked by | A blocked Issue should not be activated (or resolved, depending) until the Issues that block it are resolved. Automated Task Workflows take advantage of this link type to activate blocked Tasks once their blockers are resolved. |
| decomposes into / derives from | Indicates that high-level Issue has been decomposed (broken down) into lower-level Issues. This is a non-standard issue link! Click here for more info about creating custom link types in Jira. |
| relates to | This is a general-purpose informational link that can be created for any reason, and serves to make related Issues easily accessible. |
Issue Status
Every Issue has a Status that describes where it is in the development process. It must be one of the following:
| Issue Status | Description |
|---|---|
| Backlog | Every Issue starts in the Backlog. Backlog items are hidden from view on the Task Board. It should be easy to throw new issues into the Backlog. It is more important that they GET there than that they be well-crafted at the outset! Backlog issues are fleshed out & prioritized during Backlog Grooming Meetings. They are assigned to future Sprints and to individual workers during Sprint Planning Meetings. |
| TODO | Think of this as the Backlog for the current Sprint. Issues in this status are live but are not currently being worked on. |
| In Progress | A worker should place an Issue In Progress when he begins work on it. |
| Done | Every Issue carries its own Definition of Done. Issues go into the Done column when they have met all criteria. |
In the sections above, I mentioned an issue being activated. This means to change its status from Backlog to either TODO or In Progress.
Story Points
Below you will see references to sizing an Issue. Sizing is an attempt to guess the level of effort required for the assigned resource to complete the issue.
Sizing is intended to be a rough, conservative estimate. If an Issue is difficult to size without a detailed discussion, this is usually an indicator of one of two things:
-
The Issue is not well enough understood! Before the actual work is assigned, somebody should clarify it.
-
The Issue is too big! Before the actual work is assigned, somebody should break it up into smaller pieces.
Each of these is a great example of a Question issue, which can and should be created on the fly during Backlog grooming or any time one of these two questions comes up.
The unit of Issue Sizing is the Story Point.
Traditionally, Story Points have been a purely relative measure, not connected to any concrete work increment (e.g. man-hours). In practice, this is a little too abstract to be useful, so at Karmaniverous an estimate of one Story Point will always equal one person-day of work.
To keep things easy and conservative, Story Point estimates are drawn from a limited palette of numbers (often some variation on a Fibonacci sequence). Whatever your estimate is, choose the smallest number equal to or greater than it from the list.
Valid Story Point values at Karmaniverous are none (i.e. not yet sized), 0 (i.e. a trivial piece of work), 0.25, 0.5, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…
A two-week Sprint comprises 10 working days. An Issue may only be assigned to a Sprint is it can be completed within that Sprint. The largest valid Story Point value that fits inside a Sprint is 8. Therefore no Issue worth more than 8 Story Points may be assigned to a Sprint!
Any Issue larger than 8 Story Points MUST be broken down into smaller Issues before it can be assigned to a Sprint!
The Agile Cycle
Agile is a practice, not a philosophy. There are lots of different ways to practice Agile, but they all include most of the features described above.
At Karmaniverous, we will apply the Scrum method with two-week Sprints.
Sprints & Releases
A Sprint is a package of work that can be accomplished in a two-week period.
Every Sprint should terminate with a Release: a system milestone where everything that SHOULD work at that point actually DOES work, except for defects that are known and documented with Bugs. A Release should encompass every aspect of the system that is managed by the Agile Process, including:
- production code
- unit tests
- design artifacts
- research
- requirements
- etc.
Sprint Structure
Each two-week Sprint is framed by the following meeting structure.
| Mon | Tue | Wed | Thu | Fri |
|---|---|---|---|---|
| Standup Backlog Grooming |
Standup Sprint Planning |
Standup Sprint Review |
Standup Retrospective |
Standup Peer Review |
| Standup | Standup Backlog Grooming |
Standup |
Standup Peer Review |
Standup |
| Standup Backlog Grooming |
Standup Sprint Planning |
Standup Sprint Review |
Standup Retrospective |
Standup Peer Review |
In the Sprint structure above, the current Sprint is highlighted.
Why is this Sprint structured the way it is?
-
The mid-week start ensures continuity from one week to the next.
-
Critical once-per-Sprint meetings are never scheduled on Mondays or Fridays where they can be impacted by long weekends or other weekend distractions.
-
The middle week is left as light as possible so people can focus on tasking.
Sprint Meetings
The Scrum machine runs on meetings. These meetings are regular, clearly-defined, and most are strictly time-boxed. When a meeting’s allotted time expires, the meeting ENDS.
Never fear, it will come around again!
| Meeting | Frequency | Purpose | Length |
|---|---|---|---|
| Standup | Daily | Report progress & eliminate blockers. | 20m MAX |
| Backlog Grooming | Weekly | Refine, size, prioritize & sequence Backlog. | 1h MAX |
| Peer Review | Weekly | Peer-review work on critical Issues. | 1-2h |
| Sprint Planning | Every Sprint | Assign issues to workers in upcoming sprints. | 1-2h |
| Sprint Review | Every Sprint | Present the Sprint outcome to business stakeholders. | 1h MAX |
| Retrospective | Every Sprint | Evaluate & improve the Agile Cycle. | 1h MAX |
Standup
The daily Standup is the backbone of the Agile Cycle. Effective Standups are a strong leading indicator that the Agile Cycle is working.
In an Agile Standup, everybody takes a turn to report three things:
- What they completed since the last standup.
- What they are working on today.
- Any blockers that might prevent them from completing their assigned work.
The goal of a Standup is speed and efficiency. For that reason, Standup meetings are strictly time-boxed: the Standup begins on time, and when the timer runs out, participants are encouraged to leave. Everybody should get their turn within the allotted time, and ALL follow-up conversations take place AFTER the Standup ends.
Backlog Grooming
Everybody is encouraged to throw Issues into the Backlog as they come up. Capturing it ALL is more important than capturing ANY of it at high quality.
The Backlog will usually contain lots of Issues that are incomplete or poorly articulated. The purpose of Backlog Grooming is to go through the Backlog and…
-
Assign every Issue to the correct project Phase. Is it in scope for the current Phase? If not, let’s drop it in the right bucket & forget about it for now.
-
Size every Issue. How much work will an Issue take to resolve?
-
Prioritize every Issue. Which are the most important?
-
Sequence every Issue. What order must they be completed in to account for dependency?
-
Identify blockers. What’s standing in the way of completing this Issue?
-
Decompose complex Issues. How can we break big Issues into bite-sized pieces?
-
Fix the easy stuff on the spot, and create new tickets to account for the hard stuff, so somebody can be assigned to do the work required to flesh those tickets out.
Backlog Grooming is NEVER finished!
Trying to groom the entire Backlog every time is a recipe for failure. Instead, time-box the effort, get through as much of the important stuff as possible, and then do it again regularly.
If it looks like the Backlog is getting away from you over time, increase the frequency of Backlog Grooming meetings!
This is an iterative process! Expect to revisit the same Backlog items again and again and update dependencies, sizing, etc. as your understanding of each Issue deepens.
Peer Review
Peer review is an essential element of quality control.
Regularly-scheduled peer reviews give developers, designers, and analysts an opportunity to seek feedback from across the team on their most critical work items.
Peer review is NOT just about code. ANY Issue under active development is fair game!
Of course peer reviews can be performed at any time. The trouble is that they are often NOT done, even when they should be. Scheduling a regular availability creates space for this process to happen. In a project in progress, there will always be work worth reviewing!
Sprint Planning
The Sprint schedule is fixed: there’s a new one every two weeks. The purpose of the Sprint Planning Meeting is to decide:
- Which Issues will be assigned to future Sprints.
- Who will do the work.
What issues go into a given Sprint depends on several factors, including:
- Issue priority, dependency & size from Backlog Grooming
- Resource availability
- Business roadmap requirements
In a given Sprint, each Segment of the team (coders, BAs, etc) has a fixed amount of available bandwidth. Which Issues can fit into it, along with their known dependencies? This is the calculus of Sprint Planning.
Just like Backlog Grooming, SprintPlanning is an iterative process. Planning should look forward as many Sprints as practical, so that every Sprint is visited multiple times in subsequent Sprint Planning meetings.
Sprint Review
The Sprint Review is your team’s official dog & pony show!
The audience for the Sprint Review is your business stakeholders. This will likely be the only time during the Sprint when many of them have direct contact with the team.
Of course your goal for the Sprint Review is to impress your bosses. But just as important is to deliver an ACCURATE picture of the health of the project. Expect questions like:
- Are we meeting our timeline?
- Are we meeting our budget?
- Are we addressing concern X and meeting requirement Y?
If you pay attention, you’ll find that many new requirements are first dropped as hints in regular Sprint Reviews. So take notes!
Retrospective
The most powerful aspect of the Agile Methodology is that it is deliberately introspective: every Agile process is itself subject to the Agile process!
The purpose of the Retrospective meeting is to examine the Agile process as recently experienced by the team and make incremental improvements in order to make the team more effective.
This could take many forms, including:
- Introducing new Issue Types or changing the rules around existing ones.
- Altering Issue workflows.
- Changing the Definition of Done.
- Changing the frequency or procedures for Standups, Backlog Grooming or other meetings.
Everything is on the table! If the point of the Agile Methodology is to find out what works and then do it on purpose, then Retrospectives are how we make that a reality.
The outcome of an effective Sprint Retrospective is a change to this exact document!
