ome teams find it difficult to measure the success (or failure) of Agile projects. In many cases this is because the link between process and technology is absent and the right tools are not being used - or are not being used in the right way. In this presentation we will introduce Atlasssian products that bring agile reporting to life.
3. Presenter Background
Monte Montoya
CSM, 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
5. Scaling Agile Models
• Many people bring out the lack of metrics in JIRA.
As organizations scale, the need for reporting
needs to support:
• Release Level
• Team 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
7. Common Scaling Elements
• Foundation based on iterative planning and
delivery
• Focus on delivery of business value
• Centralized planning and decentralized decision
making
• Cross-team and Cross-organization Planning
• At each level and across teams
• Reporting on features and progress
• Alignment of requirements
11
8. Containers in Agile Tools
Collaboration Communication Planning & Refinement
Tracking & Reporting Traceability Process Enablement
Your work and containers must support your Scaling Agile
methodology
12
12. The Meaning of Release
Definition: A collection of Sprints
Purpose: Guarantee ‘shippable’ quality
All Releases
Guarantee
Deliverable
Quality
Checkpoints of known quality
Delivered at convenient intervals
Have value to justify delivery
13. Release Planning…
Release Planning produces a Release
Plan
– Estimates for Stories, Epics in Release
– Rough map of Stories to Sprints
– Dependencies between Stories, Teams
Release Planning can be expensive
– 1—3 days for all Teams and members
Value of Release Planning must justify
the cost
– Reduction in confusion due to planning
cross-Team dependencies
– Necessary to understand how external
resources may be engaged
– Required to plan for customer commitments
14. Standard Roles for Release Planning
Area Product Owner(s)
• Define Vision for Release
• Generate consistent
priorities for Release
• Make big-picture tradeoffs
Teams and ScrumMasters
• Define estimation techniques
• Estimate capacity for Release
• Understand architecture /
infrastructure implications
Team Product Owners
• Create Product Backlog Items
• Draft Release Plan, dates,
across all Teams
• Clarify requirements for Teams
Program Manager(s)
• Assists cross-Team
collaboration
• Captures Release Plan (with
cross-Team dependencies)
15. Release
Planning
Meeting
Backlog
Development
How we Plan Cross-Team Requirements
1. Write the Epic
2. Decompose Epic into Stories
3. Assign child Stories to relevant
Teams
4. Identify dependencies between
child Stories
– Create a Dependency Map
– Dependency Map is any visual
representation of dependencies
5. Estimate, schedule child Stories
for appropriate Sprints
16. Executing & Managing the Release
Executing the Program Increment:
• Teams Execute on the
Stories
• Conduct Scrum of Scrums,
Manage dependencies
• Conduct Release Meeting
• Report metrics
17. Program Team Needs
Team 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
17
Any cross-team
dependencies getting
in 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?
18. Product Team Needs
Team needs to: Prioritize and groom the backlog, need clear visibility
into status and progress of the projects
18
Any 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 progress
Communicate acceptance
criteria to the team
19. Delivery Team Needs
Team needs to: Track and manage sprint commitments, work
assignment, and impediments for optimal velocity
19
Any 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?
Let’s break this work
down…..what do we need to do
and who is taking it?
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.
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, we’ve got you covered.
Process – we’ve 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…
About Me:
-working alongside all of you. I’ve had the luxury of working closely with our trusted clients to understand pains, and solve them with:
-custom add-on’s
-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 don’t hesitate to reach out.)
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.
The background:
-In my travels to conference shows, countless customer demos and internal product meetings, I’ve 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 it’s manifesting into JIRA dashboard gadgets.
-tangile templates and such..
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: Plugin
Visualization of your release and dependency management.
So let’s 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.
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 information
We see work being spread across multiple projects
Additionally, since there is no concept of teams in JIRA, we see custom fields complicating things
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..
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 up
Program 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 software
Portfolio Level:
Initiatives that describe: what are we building, is it the right thing?
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 and…
Program 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 let’s dive into the release planning meeting.
So first things first, a release in this context will signify a collection of sprints and it’s purpose will be to guarantee shippable quality. We will look at some horizon of time and the collection of work in these iterations.
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.
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. It’s 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 more…
The murky roles and what they do:
Execute the Program Increment:
Frequent integration
Conduct Scrum of Scrums
Conduct Release Management meeting
Manage dependencies
Conduct System Demo
Report metrics
Release on Demand
Build architectural runway
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 they’ll 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?
Capabilities
Kanban boards – WIP limit and flagged issues
Open issue to view linked issues, dependencies, more feature breakdown
Open Structure – see where it is in overall priority, what teams are working on it, progress
Tempo Program board to see if feature is at risk, sprint timeline, overall capacity report
Tempo Folio to plan resources for a release – scope, budget, costs
Program Dashboard for additional metrics
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?
Capabilities
Scrum boards with epics and stories aligned next to each other, Drag&Drop to prioritize, start a new sprint
Look at reports on how epics are burning down (Feature 20) along with projected completion of epics
Look 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 team’s availability, confirm we can meet our release date.
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?
Capabilities
Work board to track current sprint activities - Drag and drop activities across columns
Track team’s velocity and sprint reports
Team timesheets
Tempo planner to track team’s capacity
Team Dashboard