Agile Reporting in JIRA
•Download as PPTX, PDF•
5 likes•2,531 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Agile Reporting in JIRA
Similar to Agile Reporting in JIRA (20)
More from Cprime
More from Cprime (20)
Recently uploaded
Recently uploaded (20)
Agile Reporting in JIRA
- 1. © 2016 cPrime Inc., All Rights Reserved JIRA Agile Reporting Presented By: Monte Montoya
- 2. About cPrime cPrime is an Alten Group Company 2
- 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
- 4. Webinar Agenda • JIRA Reporting with Gadgets • Roles & Ceremonies • Demo 5
- 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
- 6. © 2016 cPrime Inc., All Rights Reserved Project Burnup Release Metrics - progress against functionality over time Estimate Accuracy Gadget Team/Sprint Metrics - comparing PBI’s estimated vs actuals. Epic Reporting Charts Epic Metrics - viewing your large chunks of work Program Boards for JIRA Release Metrics - release planning meeting and dependency management Links will be provided in follow up email.
- 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
- 9. Delivery & Support Alignment & Reporting Strategy Levels of Organization & Hierarchy Stories Initiatives Features Portfolio Team Program & Product Team Delivery Team 17
- 10. Alignment & Reporting Strategy JIRA Organization & Hierarchy Initiatives Features 17
- 11. Release Planning Meeting Where Business and Delivery meet.
- 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?
- 20. © 2016 cPrime Inc., All Rights Reserved Project Burnup Release Metrics - progress against functionality over time Estimate Accuracy Gadget Team/Sprint Metrics - comparing PBI’s estimated vs actuals. Epic Reporting Charts Epic Metrics - viewing your large chunks of work Program Boards for JIRA Release Metrics - release planning meeting and dependency management Links will be provided in follow up email.
- 21. Metrics – Program Board Visualization Visualize your release:
- 22. Metrics – Feature / Epic Completeness Percent Feature Complete:
- 23. Metrics – Burn Up Burn Up:
- 24. Metrics – Estimate to Actuals Estimates to Actuals:
- 25. DEMO 22
- 26. Q & A 22
- 27. THANK YOU! 23
Editor's Notes
- 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