Other Jira concepts and features - Jira Tutorial

- [Instructor] In this lesson, we'll explore features of Jira and general concepts that can help project administrators and teams use Jira more effectively. Here, we'll look at gathering business requirements and evaluating considerations when structuring projects. We will also look at creating projects from a shared configuration, running parallel sprints, exploring how Jira can facilitate agile at scale, and we will examine some tips for creating successful Jira projects. We'll start with gathering business requirements. You need to understand your team's work style and project needs before you can create and configure a project that they will want to use. This involves gathering and analyzing a team's requirements and determining the appropriate Jira project configuration to meet those needs. This task is often performed by Jira administrators, but project administrators may also be involved. The goal is to create projects that your team will want to use. If you build it right the first time, it will reduce future overhead. Plan in advance; as they say, measure twice, cut once. Understand your requirements before you start building so you don't have to backtrack or undo changes. For example, if you add in the wrong custom field types and then you have to migrate data later, it's a nuisance and it wastes time. Design it well so that people will want to use it. Your project configurations should help people get their work done quickly and efficiently. Build a solution that doesn't become work itself, but instead gets out of the way and lets people focus on their job tasks. If you configure Jira well, people will want to use it. They'll have fewer change requests and they'll need less training. A successful Jira configuration needs to relate to the business where it is being used. This can help an ongoing process, for example, when you need a new scheme or project. Or maybe you've had Jira for a while, but up until now, you only used it for basic business processes and workflows, and now you need something more complex. Actual implementation in Jira can be fast. 90% of the effort is discussing and mapping out the business processes. The main steps are: first, discover and understand your organization's business requirements, then map those requirements to Jira configurations, and finally, implement them in Jira. You should spend a lot of time talking with stakeholders. This is anyone who uses Jira, including business managers, team leads, project owners, project managers, scrum masters, iteration managers, developers, and others. Business analysis involves finding and prioritizing the needs of a group of people who have different interests. That's why you need to nail it down the first time, so you've gotten a really good picture that everyone can agree on. You need to understand what the long-term goals are so your Jira configuration will be good for months or years, not just a few weeks. Once you understand the business requirements, map these to Jira configurations. Plan out what changes you will make in Jira before you actually implement them. For example, from your stakeholder meetings, you now have notes, post-its and diagrams that lay out the business processes the development teams use to take their issues from creation through to completion. And now you can formalize this information into a UML or process diagram. This gives you a clear picture of what you need to implement in Jira and includes all the workflow statuses, transitions, conditions, validators, post functions, et cetera, for each workflow. You also know, at this point, which workflow needs to apply to which development type issues. One workflow for bugs, stories and feature requests, and another workflow for all the other issue types. Finally, take your business requirements that you've mapped to Jira configurations and actually implement them in Jira. As a project administrator, you will need to work with your Jira administrator to properly configure your projects and roll them out to the team. Next, we'll explore some important considerations when deciding how to structure projects for your teams. When creating and configuring projects for your teams, a key factor is deciding how many projects to create. Can multiple teams share a project, or is it better to create individual projects for each team? In the next few slides, we'll explore some important considerations to help you decide. Having multiple teams share a single project can be effective when all teams are working from the same roadmap and are contributing to a coordinated product release. Also, if a common set of permissions and workflows can effectively satisfy team needs, then a single project is also a good fit. Other considerations include the need to share work output, having a single source of sprint planning and shared reporting. When teams work from independent roadmaps that don't require coordinated releases and each team has its own permissions and workflow requirements and plans its sprints differently, then creating individual projects for each team is usually the best approach. With separate projects, reports can be run on each individual project. Even when teams are working in their own separate projects, their work can still be coordinated at a higher level by rolling the projects up to a common epic. The teams still work independently, but contribute to a common initiative. Overall progress can be tracked by monitoring the epic. Next, we'll look at creating projects by sharing configurations. A scheme is a container or a collection of configuration items. There are many different types of schemes, and each one behaves slightly differently. Schemes enable administrators to create a package of configurations and then apply the package to multiple projects, eliminating the need to recreate the same configuration settings every time a new project is created. For example, here you see an issue type scheme that contains issue type definitions that will be used in the teams' projects. You can see the Jira administrator has added the feature request Issue Type. The Jira administrator then associates the scheme with all projects that require this issue type configuration. Without schemes, the Jira administrator would have to configure the issue types for each project individually, which would be a lot of work that would need to be repeated whenever a new project is created. When you create a project, you can choose to share settings from an existing project. You do this when creating a new project that is similar to an existing project and you believe the requirements will stay the same. For example, the payroll team lead wants a new project and she sets it up just like the HR project. If a changes made to one project with shared configurations, that change affects all the projects that share the settings. Projects that share configurations, share issue types, workflows, screens, fields, versions, components, permissions, notifications, and more. Lower-level configurations, such as role assignments and board configurations, are project-specific and are not propagated to other projects. Using shared configurations provide several significant benefits. Every time a new project is created, Jira creates unique configuration objects for that project, which can be a headache to maintain as the number of projects continues to grow. By sharing configurations, the number of unique configurations is kept to a minimum, which helps troubleshooting and overall maintenance of Jira. And perhaps most importantly, shared configurations promote consistency across projects. For ease of operation and maintenance, the Jira administrator can create template projects with common configurations used by your organization. Then, whenever a new project is created, it can use shared configurations based on one of these template projects. In this way, all of the possible project configurations are known and any changes to the template projects will automatically be propagated to all shared projects. When creating template projects, try to create as few as possible. Create just enough to articulate key differences. The most significant differences are typically workflows and permissions, so consider those first. Now, we'll look at running parallel sprints. This requirement calls for multiple teams to simultaneously run sprints from the same backlog. By default, Jira only allows one sprint to be active in a project at a time. Normally, a project can only have one active sprint at a time, but the Jira administrator can enable parallel sprints for the entire Jira instance. This enables projects to have multiple active sprints. However, all teams will need to use the same estimation metric since they're working from a common backlog. Keep in mind that when running the velocity chart report against the project, the report will not segment velocity by individual team. Jira doesn't offer the option to divide a board into swim lanes by sprint. You can use the query swimlane condition and JQL statements to create swim lanes by sprint, however, you will need to modify the query. every time a new sprint is started to include it in the query, so it's not a very scalable option. By making the sprint field visible on cards, the respective sprints can be easily identified. Use the Sprint drop-down to isolate issues from specific sprints on the board. You must do this first when completing a sprint, since only one sprint can be completed at a time. Now, we'll take a brief look at how Jira can help organizations scale their agile practice. Agile at scale is defined as the ability to drive agile at the team level, while applying the same sustainable principles, practices, and outcomes at other layers of the organization. For example, if agile teams do pre-sprint planning three days before a sprint begins, then project managers will want to do pre-quarter planning two to three weeks before the start of the quarter to ensure a properly prepared backlog across a team of agile teams. There are many ways to conceptualize the agile journey. One is to think in terms of how teams and individuals adopt agile behaviors. The model on the slide describes five stages to consider, starting with the initial adoption at the team level that gradually expands to adoption by cross-functional teams and eventually the entire organization. Full enterprise agility doesn't happen overnight. It's a process that happens gradually. By scaling your agile tools, the agile practice can be supported at scale, and key agile benefits can be applied throughout the organization. Transparency: When your team's work is tracked in a tool, other teams, including your leadership team, have visibility into the work being done. Tools can serve as a single source of truth to keep everyone on the same page, even if they're not based in the same office as you. Consistency: when individual product or program teams track work in their own ways, a lack of consistency can make it hard to visualize work across multiple teams. Predictability: Tools can help calculate velocity, capacity and other important measurements to help you determine when your team's work will be on time or not. For organizations with up to 20 agile teams working together, Advanced Roadmaps for Jira, formerly Portfolio for Jira, helps plan a build, see the big picture, track progress, and easily share information with stakeholders. It provides a single source of truth into the current and future health of your initiatives. Using plans, you can create reliable forecasts of your team's work in Jira while keeping track of current work across realistic schedules in an ever-changing agile environment. Advanced Roadmaps enables realistic strategic planning, regardless of how many or people you have working towards your goals. Together with Jira, Advanced Roadmaps provide a single source of truth for the current and future health of your initiatives. For an enterprise-wide agile practice, Jira Align connects your business strategy to technical execution, while providing real-time visibility. It allows enterprises to aggregate team level data and make all work visible across your enterprise in real time. All layers of scale are connected and everyone can get on the same page to determine scope, roadmaps and dependencies across teams and portfolios. You can easily connect strategic investments with customer value created in order to drive outcomes faster and more reliably. It offers out-of-the box support for all the most popular scaling frameworks, such as SAFe, Scrum@Scale, Spotify, LeSS and more. It allows configuration of customized, internally developed frameworks. Terminology can be customized to accommodate custom or hybrid models. We'll finish with some guidelines for successful projects. Keep it simple. Complexity does not equal usefulness. Keep workflows, board configurations, dashboards and project configurations simple and straightforward. Reuse often. When users and teams are unwilling to standardize business processes, it becomes a barrier to entry for users to change teams and makes administration more complicated. Using shared configurations promotes consistency and predictability. Use name conventions. Standardize how projects, boards and sprints are named to make projects easier to maintain and understand. Provide context in your names, such as a prefix that includes a feature name, a business unit. or something recognizable to make searching easier. Test the environment. Before rolling out new configuration changes, it is advisable to try them on a test site or a test project. Satisfy requirements. A project can only succeed if the team adopts it. So, always try to create and configure projects to meet your team's requirements. It's important to take time to thoroughly gather requirements and work processes. Create role-specific dashboards. Create dashboards that are tailored to specific roles so that relevant information is made available to the right people. Okay, now a little quiz. Which of the following are benefits of using shared project configurations? A: Only one project administrator for all projects. B: Promotes consistency across projects. C: Every project uses the same board. Or D: troubleshooting problems is easier. The answers are B, promotes consistency across projects, and D, troubleshooting problems is easier. Since multiple projects share the same configuration, projects can be managed and maintained in a consistent manner. By sharing configurations, the number of unique configuration objects in the system is reduced, and the ones being used are well-known, making troubleshooting less difficult. Key takeaways from this lesson include, understand what your team needs before creating and configuring projects, use shared project configurations whenever possible to promote consistency and simplify maintenance, and leverage Jira's ability to scale to support increased agile adoption in an organization.