Agile Reporting in JIRA

Editor's Notes

• #2: 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.
• #3: 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…
• #4: 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.)
• #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.
• #6: 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..
• #7: 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.
• #8: 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.
• #9: 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
• #10: 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..
• #11: 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?
• #12: 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.
• #13: 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.
• #14: 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.
• #15: 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…
• #17: 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
• #18: 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
• #19: 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.
• #20: 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