JIRA & Confluence Detailed Management Plan
Purpose
This guide is a living document that should be customized to fit the needs of the project team. The team will decide whether specific details need to be added to ensure that JIRA and Confluence are used as efficiently as possible. For example, the team may decide that specific labels are required to be attached to JIRA tickets that indicate when the ticket is ready for review.
< This page should be deleted before sharing with the team >
Table of Contents
Working with JIRA and Confluence at Apigee
JIRA
Creating user stories in JIRA
Planning and Managing JIRA with the Agile Board
Sprint Board Configuration
CONFLUENCE
Confluence Updates
Formatting Confluence Pages
Working with JIRAand Confluence at Apigee
Apigee’s Accelerator Methodology is used to implement Customer Success projects. It embraces Agile philosophy and is based largely on the Scrum development framework. Like Scrum, our Accelerator development approach includes four key roles: Product Owners, Scrum Masters, Architects and Developers. It’s important to understand how these roles work with user stories on Apigee projects.
Customer Success functions as the professional services arm of Apigee, so our customers typically represent the “Product Owner” role. Apigee architects and developers generally fill the Architect and Developer roles, while Apigee Scrum Master role helps the team follow the process.
JIRA
JIRA is our chosen user story tracking software. This document is not meant to provide JIRA training, but is intended to provide the guidance necessary to create user stories within JIRA and begin to plan work. For those purposes, there are two areas of JIRA that we’ll focus on: the Create Issue screen and the Agile Board.
Creating user stories in JIRA
Once you have access to JIRA, to create a new user story, select “Create Issue” from the top menu. This brings up the Create Issue screen. At its heart, JIRA is an issue tracking tool. So, it treats a user story as a type of issue.
First, confirm that the intended customer (or referred to as project) is selected for the user story as Apigee resources may have access to more than one customer account. Then set the Issue Type to “Story.” This will make the issue behaves the way intended during planning sessions and provide some story-specific features that we may want to use.
Remember the card metaphor described earlier. This issue is essentially a digital version of a card to write your user story, albeit with several more fields of information. Most of the fields can be ignored when you first create a story, so we’re only going to focus on a few and each customer should define their standard for capturing all the necessary details. This table highlights how certain fields should be used (or not) when creating a user story:
Section 1.01Field
/Section 1.02Input
Summary / Put the user story title here.Priority / Select the priority level of your user story. This will be helpful when planning sprints. Remember that priorities may change over time, so keep it up to date.
Due Date / Due dates are not required on user stories and should not be used unless a user story corresponds with a known committed delivery date. If so, then this is important to sprint planning.
Assignee / Do not set the assignee field. User stories should be self assigned by the developers during the Extreme Sprints.
Description / Enter the user story narrative. Additional description can be added if needed for context. If your project lacks an acceptance criteria field, this should be put in the description as well.
Original Estimate / This field only accepts time estimates, which was noted as not the best practice for user stories. Using this is the scrum master’s choice. Note that JIRA’s agile board provides for estimating with “story points,” but this is not available in the create issue screen.
Attachment / Not required, but sometimes a user story begins as a drawing or relates to a screenshot. Attaching these can facilitate user story conversations. Implementation information in docs or spreadsheets can also be attached, but it is sometimes best to attach this to specific tasks or make it available on the project wiki. This may also be the place that attached calls and responses are entered for user story acceptance.
Labels / Labels are metadata that can assist with searching for and filtering issues. Consider adding relevant labels to your story to help organize and track stories..
Epic Link / Epics are large stories that are more like a theme and less actionable than user stories. They also tend to span across multiple sprints. JIRA treats epics as a different type of issue so that they can function differently in the system. Linking to a related epic allows you to associate your user story with it, which can be handy when planning and to use Epic Reporting to show stories implemented and pending to complete an Epic.
Acceptance Criteria / Acceptance criteria should be part of a user story before work on it begins. This is a custom field that is not always available to new issues (depending on if added). If it is not, add acceptance criteria to the description field or explore how to add a custom field to your project.
Once you’ve entered the appropriate information and created the issue, congratulations, you now have a user story ready that’s ready to get to work. There are some additional things to keep in mind with user stories after they are created in JIRA:
•Team members can comment on JIRA issues and attach files. In this way, user stories can be great containers for capturing conversation details and key decisions.
•Stories can linked to other stories and tasks. This is a good way to denote related stories and work that might influence the story and provide team members an easy way to navigate between them.
•Stories can contain sub-tasks, which are issues embedded in the story itself and must be complete before the story can be closed. These can be useful, but have limitations, such as not being visible as individual tasks on the Agile planning board.
•All JIRA issues, including stories, show a status. This status will change as the user story makes its way through the story workflow.
•Work on story should not begin until it is planned as part of a sprint and assigned to a team member.
Planning and Managing JIRA with the Agile Board
Note: Every new project added to JIRA should have an agile board available to it for planning and extreme sprint management.
JIRA’s Agile board feature allows issues to be thought of more like traditional user story cards for planning, enabling the team to drag issues into sprints and from status to status as would occur on a physical planning board. Going into detail about how to use the Agile features is outside the scope of this this page, however there are some important Agile board concepts that relate directly to how to work with user stories.
An agile board has three main screens (Plan, Work and Report), each allowing you to work with user stories differently:
The Plan screen is for backlog grooming and sprint planning.
•It allows the team to see what stories are in the backlog and prioritizes them in a list (called “ranking”).
•When you create a story, it is automatically part of a backlog and visible on the board.
•Selecting a story in the plan view has details of the screen appear to the right. This view allows you to enter a “story point” estimate, not to be confused with the time-oriented “original estimate” field in the create issue screen. Since estimates should be done with the development team, and this screen is meant to facilitate planning sessions, this is an appropriate place to enter a point value to “size” the story.
•During sprint planning, you drag stories that to add to a sprint from the backlog and rank it within the smaller sprint backlog. User stories may be assigned for the upcoming sprint at this time.
•Adding a user story to a sprint sets an expectation that work on the story will occur in the sprint, but does not reflect work has actually begun on it yet.
The Work screen is dedicated to working with issues added to the current sprint. It is geared toward managing and reviewing story status during a sprint.
•When a story’s assignee begins work on the story, they should set the status to in-progress (either on the issue or by dragging it from the planned column to in-progress). This will be reflected on the work screen, which facilitates sprint standup meetings and provides a quick visual of what is left to do in a sprint.
•This is also a good screen to assign or reassign stories as necessary during the sprint.
The Report screen provides the team views of how work is progressing during a sprint. There is little action to take on issues directly, however it does provide another view into the sprint progress.
Sprint Board Configuration
During each customer engagement, the Agile sprint board can be configured based on customer needs or requests. The scrum master can configure the sprint board by selecting the ‘Configure’ option from the ‘Board’ drop down menu located in the top right corner of the Agile sprint board.
There are numerous configuration options to choose from and the following areas may be useful to configure based on customer needs: Columns, Swimlanes, Quick Filters, Card colors, Estimation, and Working Days.
The Column Managementpage allows for customization of each column shown on the sprint board. Additional columns may be added, the titles of existing columns can be edited or the order of columns can be changed.
The Swimlanespage allows multiple swimlane types to select from when grouping issues.
The Quick Filterspage provides configuration for creation of new quick filters that can be used by team members during each sprint.
The Card Colors page allows assignment of colors based on issue type, priorities, assignees, or queries.
The Estimation page allows for detailed time tracking if ‘Remaining Estimate and Time Spent’ is selected as a configuration option.
The Working Days page allows for configuration of time zone, non-working holidays, and workdays for each customer engagement.
CONFLUENCE
Confluence is our chosen software to manage customer engagements, and a page should be created for each individual engagement. The home page for each engagement should include, at a minimum, the following sections:
Status Menu Header– provides green/yellow/red status updates on 5 standard categories
Summary Reports – provides link to latest Weekly status report
Customer Team – lists key customer team members
Apigee Team– lists key Apigee team members
Key Milestones – provides upcoming visibility on key milestones for customer engagement
Project Documents – lists relevant documents to reference during customer engagement
Confluence Updates
The scrum master is responsible for providing weekly updates to the Confluence page. The status menu header includes the 5 standard categories of Overall, Schedule, Scope, Budget, and Resourcing.
These status categories should be evaluated as green / yellow / red based on the following definitions:
Green - Aligned with customer and executing as expected. May be exceeding expectations.
Yellow - We may have an issue and need to ensure we monitor this to ensure this doesn't become an issue. Early warning.
Red - Something requires action to realign for delivery of the project.
Formatting Confluence Pages
When managing Confluence, keep in mind that customers will have access to the Confluence site for their engagement so what is displayed on the home page will be seen by all. This should be a guiding principle even if your customer doesn't currently want to use Confluence as they may change their mind.
All budget information should be placed into the "Apigee Internal Project Documents" folder and only communicated to key resources on your engagement team.
Child pages can be created for additional topics such as ASU reports, Weekly Status reports, implementation schedule, resource plan, meeting notes, and other areas as required by each customer engagement.
1
About Apigee
Apigee empowers enterprises to thrive in today’s digital world by transforming digital assets into innovation engines. Results are delivered as apps, optimized by data and catalyzed by APIs. Hundreds of companies including Walgreens, eBay, Shell, Bechtel, Marks & Spencer & Vodafone partner with Apigee to accelerate their digital transformations.
To learn more, visit