Slide 1

JIRA Agile Reporting

Presented By: Monte Montoya

2016 cPrime Inc., All Rights Reserved

Hi and welcome to our next webinar on JIRA Agile Reporting with Gadgets. We are excited you could join us today to talk about JIRA Gadgets for Reporting.1

About cPrime

cPrime is an Alten Group Company2

A little bit about us:

We are: A software services lifecycle management company specializing in unifying your software and service implementations.We have dedicated practice leads committed to people, process and technology initiatives.People we provide great people to augment your team. Wether that be contract to hire, Full time hires or team members, weve got you covered.Process weve been helping organizations scale their process with transformation services for the past 10 years.Technology we implement and optimize your agile management software and leverage our critical channel partnerships in across the ALM stack.

Need to unify the Software and Services** Tools and technology should be aligned

2

Presenter BackgroundMonte MontoyaCSM, CSPO

Over the past 5 years, Monte has been managing software development and process development projects for Fortune 500 companies. His experience with the Atlassian clients has been in designing and building custom Atlassian products and Atlassian solutions.

He has helped companies like Apple, PayChex, Enterprise Rent-A-Car, Uber, The Tradedesk and more.4

About Me: -working alongside all of you. Ive had the luxury of working closely with our trusted clients to understand pains, and solve them with:-custom add-ons-custom integrations-migrations and more-gathering requirements and adding value with technology solutions has been a great ride with Atlassian. -worked on first JIRA SAFe solution (if you are interested in learning more about this configuration please dont hesitate to reach out.)3

Webinar AgendaJIRA Reporting with GadgetsRoles & Ceremonies Demo

5

OK, so today: We will be talking about:-Release and Team metrics and how we are using some cool new custom gadgets to uncover gaps, raise up insights so that we can ultimately have more informed conversations. -we will also talk about roles and ceremonies in an effort to drive value and cut down on Program managers and PMO from having to use Excel. -finally, we will launch into a full demo after a few short slides to Demo these use cases.

4

Scaling Agile ModelsMany people bring out the lack of metrics in JIRA. As organizations scale, the need for reporting needs to support:Release LevelTeam Level Role-Based Ceremonies

Each of these can be interpreted differently by organization but we will start with a few.

Your tools must support your organizations methodology!

6

The background:

-In my travels to conference shows, countless customer demos and internal product meetings, Ive had the chance to talk to so many customers, and the narrative is JIRA is light on reporting and metrics. -I commonly hear.. How do I get this report or that-Now, while you can do anything from thw API, we decided from to tackle this problem head on by building a couple key customer requirements in an effort to bring our thought leadership and Agile knowledge to Atlassian. -So, we built a few Dashboard gadgets that compliment program managers, product managers and team members. -We are now opening up our Agile cirriculum and now its manifesting into JIRA dashboard gadgets.

-tangile templates and such..

5

Project BurnupRelease Metrics - progress against functionality over time

Estimate Accuracy GadgetTeam/Sprint Metrics - comparing PBIs estimated vs actuals.

Epic Reporting ChartsEpic Metrics - viewing your large chunks of work

Program Boards for JIRARelease Metrics - release planning meeting and dependency managementLinks will be provided in follow up email.

2016 cPrime Inc., All Rights Reserved

The gadgets and plugin we will show today are pieces that will only augment your roles and ceremonies.

Project Burn Up: A dashboard gadget built to show how much work was actually accomplished during a given iteration vs. how much work remains to be completed

Estimate Accuracy:A dashboard gadget to better report on the delta between backlog items. Comparing estimates and actuals. -Or planned vs. actual (e.g. task slippage) information.

Epic Reporting Charts:summary to communicate the epic's overall status

Program Boards for JIRA: PluginVisualization of your release and dependency management.

6

Common Scaling ElementsFoundation based on iterative planning and deliveryFocus on delivery of business valueCentralized planning and decentralized decision makingCross-team and Cross-organization PlanningAt each level and across teamsReporting on features and progressAlignment of requirements11

So lets talk about the big elephant in the room. What are the common elements of a scaled solution.

-Has to have some foundation of Agile-Has to be built around business value-some system of planning and decision making-multi-leveled alignment approach from Portfolio to Program and on down to component teams. - finally, you must be able to measure and report on progress and understand features and completeness.7

Containers in Agile Tools

CollaborationCommunicationPlanning & RefinementTracking & ReportingTraceabilityProcess Enablement

Your work and containers must support your Scaling Agile methodology12

Based on these scaling elements, the next set of challenges comes from how organizations are spreading their work across their JIRA containers.

-This has been one of the single biggest disconnects that cPrime has been addressing with services for the past few years. We see organizations using one project and filtering down the project to get specific and relevant informationWe see work being spread across multiple projectsAdditionally, since there is no concept of teams in JIRA, we see custom fields complicating things8

Delivery &SupportAlignment & ReportingStrategyLevels of Organization & HierarchyStoriesInitiativesFeatures

Portfolio Team

Program & Product Team

Delivery Team

17

From this perspective, we see some common use cases for various levels in an organization. -We have data to support that the most commonly used levels of hierarchy are-Portfolio / Initiative level-Program / Feature level-Team / component teams working on issue types like stories, bugs, tasks, spikes, risks, trackers, etc..

9

Alignment & ReportingStrategyJIRA Organization & HierarchyInitiativesFeatures17

So what does this look like from a JIRA organization and hierarchy? -as you can see here, we have the 3 levels we discussed however, a few items to note:

Starting from the bottom, we have:Team Level-component teams working on pieces of functionality-standardized workflows are critical to normalizing the data-issue types are a connected and roll upProgram Level-feature or epic based boards -standardized workflows that are specific to the ceremony-issue types like features all correspond as a rolled up piece of the functional softwarePortfolio Level:Initiatives that describe: what are we building, is it the right thing?

10

Release Planning MeetingWhere Business and Delivery meet.

The Epic or Feature or (whatever nomenclature you use), is where business and delivery meet. It is the critical part of the release planning meeting andProgram managers commonly need to visualize their work over time, They need to identify and understand dependencies, They need to have more informaed conversations regarding cross team issues, etc. So lets dive into the release planning meeting.

11

The Meaning of ReleaseDefinition: A collection of SprintsPurpose: Guarantee shippable qualityAll ReleasesGuaranteeDeliverableQuality

Checkpoints of known quality

Delivered at convenient intervalsHave value to justify delivery

So first things first, a release in this context will signify a collection of sprints and its purpose will be to guarantee shippable quality. We will look at some horizon of time and the collection of work in these iterations.12

Release PlanningRelease Planning produces a Release PlanEstimates for Stories, Epics in ReleaseRough map of Stories to SprintsDependencies between Stories, TeamsRelease Planning can be expensive13 days for all Teams and membersValue of Release Planning must justify the costReduction in confusion due to planning cross-Team dependenciesNecessary to understand how external resources may be engagedRequired to plan for customer commitments

In your release planning meeting we want to be sure we are capturing a few critical items:The meeting should produce a release plan with:-some estimates for stories and epics as a part of the release-a rough visual map of stories to sprints-highlighting dependencies across your teams or among your issuetypes.

13

Standard Roles for Release PlanningArea Product Owner(s)Define Vision for ReleaseGenerate consistent priorities for ReleaseMake big-picture tradeoffsTeams and ScrumMastersDefine estimation techniquesEstimate capacity for ReleaseUnderstand architecture / infrastructure implicationsTeam Product OwnersCreate Product Backlog ItemsDraft Release Plan, dates, across all TeamsClarify requirements for TeamsProgram Manager(s)Assists cross-Team collaborationCaptures Release Plan (with cross-Team dependencies)

The formalized Roles are in brown are all part of the process. However we find that some roles become blurred after you leave the team level. How do we address these?

The team roles are clearly defined here in JIRA. Its the program manager and product level that seem to need more definition.

We commonly see that the program manager is tasked with the huge responsibility to drive cross team collaboration, capture the release plan and more14

Release Planning Meeting

Backlog Development

How we Plan Cross-Team RequirementsWrite the EpicDecompose Epic into StoriesAssign child Stories to relevant TeamsIdentify dependencies between child StoriesCreate a Dependency MapDependency Map is any visual representation of dependenciesEstimate, schedule child Stories for appropriate Sprints

Executing & Managing the Release Executing the Program Increment:

Teams Execute on the StoriesConduct Scrum of Scrums, Manage dependenciesConduct Release MeetingReport metrics

The murky roles and what they do:

Execute the Program Increment:Frequent integrationConduct Scrum of ScrumsConduct Release Management meetingManage dependenciesConduct System DemoReport metricsRelease on DemandBuild architectural runway16

Program Team NeedsTeam needs to: determine if the release date will be met and test some what-if scenarios to determine what changes can be made to ensure the release date is met

17Any cross-team dependencies gettingin the way?Where are we in process of delivering our features?What percent of the feature is complete? Are we going to deliver in budget and on-time?What are the details of this feature? Are there multiple teams working on it?Can I see Program dashboard of most important metrics?

Next lets take a look at our program Teams. Their main goal is to coordinate activities and to ensure the delivery of the release. So what are they are doing to achieve that goal? They are going to look at where we are in the process, are we focused on the right things.and theyll need to understand the impediments.

Lets go take a look on how they will perform few of these activities.

So we looked at the overall health of our features. Any questions?

CapabilitiesKanban boards WIP limit and flagged issuesOpen issue to view linked issues, dependencies, more feature breakdownOpen Structure see where it is in overall priority, what teams are working on it, progressTempo Program board to see if feature is at risk, sprint timeline, overall capacity reportTempo Folio to plan resources for a release scope, budget, costsProgram Dashboard for additional metrics

17

Product Team NeedsTeam needs to: Prioritize and groom the backlog, need clear visibility into status and progress of the projects18Any cross-team dependencies getting in the way?Confirm ranking of the backlog is in alignment with top ranked features

How is our release progressing?Communicate changes to work in progressCommunicate acceptance criteria to the team

Next lets take a look at our product teams. Their main goal is to coordinate activities and to ensure the delivery of the release. So what are they are doing to achieve that goal? They are going to look at their backlog, prioritize and groom it, and manage dependencies.

Lets go take a look on how they will perform few of these activities.

So we looked at the overall health of our features. Any questions?

CapabilitiesScrum boards with epics and stories aligned next to each other, Drag&Drop to prioritize, start a new sprintLook at reports on how epics are burning down (Feature 20) along with projected completion of epicsLook at reports on how release is burning down (WDP Greencloud new web page)

As a Product Owner my goals is to ensure timely release. My main activity is grooming the backlog so the team knows what to work on.To do this, I'll be ranking the backlog, communicating the details of the backlog, ensuring dependencies are met, determine teams availability, confirm we can meet our release date.18

Delivery Team NeedsTeam needs to: Track and manage sprint commitments, work assignment, and impediments for optimal velocity

19Any cross-team dependencies getting in the way?We have room in the sprint to take on next item? Which one?What have we completed?Do we have capacity to take on more in this sprint?What is our remaining ToDo?What discussions did our offshore team have yesterday?What is our velocity?

Lets break this work down..what do we need to do and who is taking it?

Next lets take a look at our delivery teams. Their main goal is to track and manage sprint commitments for optimal delivery. So what are they are doing to achieve that goal? They are going to look at their workboard, prioritize and groom it, and manage dependencies.

Lets go take a look on how they will perform few of these activities.

So we looked at the overall health of our features. Any questions?

CapabilitiesWork board to track current sprint activities - Drag and drop activities across columnsTrack teams velocity and sprint reportsTeam timesheetsTempo planner to track teams capacityTeam Dashboard

19

Project BurnupRelease Metrics - progress against functionality over time

Estimate Accuracy GadgetTeam/Sprint Metrics - comparing PBIs estimated vs actuals.

Epic Reporting ChartsEpic Metrics - viewing your large chunks of work

Program Boards for JIRARelease Metrics - release planning meeting and dependency managementLinks will be provided in follow up email.

2016 cPrime Inc., All Rights Reserved

Metrics Program Board VisualizationVisualize your release:

Metrics Feature / Epic Completeness Percent Feature Complete:

Metrics Burn UpBurn Up:

Metrics Estimate to ActualsEstimates to Actuals:

Demo22

Q & A22

Thank you!23