Jira is one of the most flexible most powerful Agile team management tools that there is. All that power is its greatest strength - maybe also it’s its greatest weakness. Jira can be a little overwhelming at first. But just a few key things will get you pretty far toward harnessing安上马具,引申为驾驭 the power of it all.
I’m Dan Chuparkoff and today I’m putting those key things you need to master Jira and Agile team management all here in this video so you and your team don’t have to stumble through it on your own.
The JIRA project is the highest level container. You can think of the Jira project as a table in a database.
A single Jira issue can only exist in one Jira project at a time.
From Jira’s home dashboard you can see your projects by clicking the projects menu over there in the left navigation bar.
From this projects listing page you can see and access your existing projects or you can create a new Jira project just by clicking the create project button at the top right. That’s enough to get you started.
But while we’re here, don’t get too caught up in the actual definition of the word project. When Jira was created back in 2003, the word project often referred to a much bigger collection of work - sometimes stretching over years of development.
These days, projects are much more Agile. Your team is probably juggling lots of project work. Don’t let the semantics of that word lure引诱 you into scattering分散 your team’s work into a million different fragments. Trust me. Put all of your team’s work into a single Jira project.
We’ll use some of the other attributes of Jira to allow you to divide it up into contextual views. I’ll explain this a lot more in the sections later in this video on Epics, Components, Labels, and Boards.
Next, let’s talk for a second about the types of Agile.
As you create your first new Jira project, you’ll notice that you have a few options for what happens next.
25
00:01:35,259 --> 00:01:37,989
you’ll notice that you have a few options for what happens next.
There are two fundamental styles of Agile work management: Kanban and Scrum.
Don’t worry. This is an easy distinction once you understand the basics. Here’s a quick and easy breakdown of each so that you can quickly and confidently find the work style that will set your team up for success.
Scrum Agile is best for teams that are working on new features with a tight schedule for finishing their work as they try to align with a projected launch target or the coordination with delivery from other teams.
Scrum teams manage their way toward this projected target by breaking their work up into iterative batches that we call Sprints.
Most high-performing teams agree that two weeks is a good length of time for Sprints.
Imagine you are working on a software team implementing new features. In this case, a large amount of your work is defined in a Backlog near the beginning of the project and you’re most likely working toward an incremental milestone or the ultimate projected launch date. Your team will still encounter unknowns and you will, of course, still learn new things along the way. So it’s normal, acceptable, and even encouraged to refine and redefine some of your work as you proceed. But an important distinction here is that when new work is discovered in the middle of an active Sprint, the existing in-progress work is left to proceed as it is and that new work is added to the next Sprint. Because you’re Agile, that next Sprint should be right around the corner. So to summarize: in Scrum, teams collect all the work that needs to be done, they put the work in the right order, they define checkpoints for completion of batches of that work, and then they reprioritize at each checkpoint. That’s scrum. And each of those iterative batches of work is a Sprint. Creating a new Scrum project is even easier in JIRA. After you name your new project, you’ll notice that the Scrum workflow template is already the default option. Just click the Create button and you’ll be off and running. Now we have a project in JIRA, but it’s empty. So we’re going to create some issues. In all kinds of Agile, teams break their to-dos down into small manageable snippets. This breaking of work into fragments helps to ensure that ownership of every task is clear and that teams can reprioritize as often as their world changes around them. It also helps to ensure that the work can be delivered to customers and stakeholders as quickly and as often as possible. If your team is new to Agile methodologies, breaking tasks down is the most important thing to try first. This rapid, iterative delivery of progress is the thing that makes teams Agile in the first place. When referring to all the bits of work in this system, JIRA uses the word, ‘issues’. When I refer to a collection of issues in JIRA, I often say ‘tickets’ instead. Because issues sounds like something’s broken and this often isn’t the case. Creating a new issue in JIRA is easy. Just click that white + icon over on the left of the menu bar. As you can see, there are only three required fields. And the first two of these fields, Project and Issue Type will be filled out for you based on the last ticket you’ve created. This means that you’re always just a create button click and a summary text box away from logging your work into your team’s JIRA instance. As you learn to customize your JIRA experience, remember to keep it simple. Limit the number of required fields on your Create Issue screen to the smallest number possible. If you really want to improve the visibility to the things your team is juggling then you want logging work, so that it doesn’t slip through the cracks, to be quick and easy. Creating issues is simple. Figuring out what to put in them is a little trickier. When you break work down into tasks, try to break your work down into small enough fragments that you can reprioritize as often as you have new ideas and discover new things that need to be done. The right size for your team will depend on the maturity of your project and the length of time between delivery checkpoints. But many Agile teams find that the following rules are good upper and lower targets to aim for.
When you creat new tickets, you have an option called issue type.
Issue type allows you to distinguish between the different types of work for your team.
Your options are Stories, Tasks, and Bugs.
Epic is also an issue type in that list, but ignore that one for now. It’s a special issue type and it behaves a little differently when you choose it.
WHEN you choose stories, Tasks and Bugs, aside from changing the icon next to the issue in all the display screens, this doesn’t really affect that much. You can think these as synonyms同义词.
When you want to get a little more granular更细粒度, you can break down like this.
Issue details
In addition to the basics, there are a few attributes will come in really handy especially as the list of tickets for you team gets large.
Before we can use them, we need to enable the additional field on the created issue screen.
At the top right of the screen, notice the drop down box that says “configure fields”.
click it, the ten most commonly used additional fields are here and you can easily add them to your create issue screen just by checking the corresponding checkbox.
Many of these fields are useful, try them out yourself.
We’re going to talk about some of labels and componets fields’ differences next, so we are just going to add these two fields to create issue screen.
While we’re here, I will add one more field that will come in handy later: the story points field.
Sadly, story point field is not on the ready-to-add fields list. But still, JIRA makes adding this additional field fairly easy. If you are looking for any field wasn’t on the configure fields list, try this!
CLICK the configure fields drop-down box again.
Now, click the “where’s my field” link.
Start typing a field that you’re looking for - the type-ahead search will most likely find it for you.
When you find what you’re looing for, select it. The where’s my field wizard will give you an expanation of why this field isn’t there. There are lots of words, just scroll down, you can see:"The ’ ’ filed is not included …To solve this problem, go to ‘a link’.
Click the link that follows. Clicking this link takes you over to JIRA’s settings section. There’s a lot of stuff that you can change over at the left when you’re ready to customize your JIRA instance to match the way your team works. But don’t worry about that stuff for now.
Just type the field you were looking for once again in the select-field box at the bottom. Typing story points here and hitting “enter” will add it to the configure field list on your Create Issue screen.
Now, go back to your Create Issue screen. Click the configure fields drop-down again. Check the checkbox next to the “Story Points” field, and from now on, you’ll see this field at the bottom.
Once your whole team is using JIRA for all of its work, you’re going to want a way to start sorting through the long list of tickets.
Labels and Components can help.
These are both effectively the same things.
Labels and Components are just tags applied to issues.
Once these tags are there, you can filter on them later in an issue search, with boards, or with quick filters on a board.
If you put all of your team’s work into a single project, then this will help you to differentiate between contextual subsets of your work.这将帮助你区分工作的上下文子集。
Although Labels and Components are very similar, there’s one key difference. 尽管非常相似,但是有一个关键的不同点。
Labels are just tags.
Components are also tags.
Also, When my teams are juggling multiple work on multiple products at the same time, I prefer using Components to allow me to segment the work by product instead of putting their work and different JIRA projects.
The tools you need to actually do some work
In a scrum project, when you create new JIRA issues, they end up in the backlog where you can prioritize your team’s work and arrange it into two-week delivery batches called Sprints.
This process is called Sprint Planning and it’s typically done at the beginning of every Sprint.
You can see here that I’ve added some more Stories and Tasks to our Backlog.
Once there are tickets in your project’s Backlog, you can use this view to prioritize the work into Sprint-sized blocks. Let me show you what I mean.
You create the next few upcoming sprints on the Backlog view. I’m going to do that now.
Here’s a tip. Since there are 26 two week periods in a calendar year and also 26 letters of the English alphabet, I often use letters to name my sprints so we can talk about them as memorable objects. Everyone on the team, conversationally will easily be able to say, "we can’t do this in the F sprint, but we should try to make sure it gets done in the G, H, or I Sprints.
" When your team wants to makethis a little more fun, you can code name the Sprints using themed words that start with sequential letters of the alphabet: like the Ferris Bueller sprint, the Gordon Gekko sprint, the Hal 9000 sprint, and the Inigo Montoya sprint.
Although it’s really just a tag in Jira, an Epic should be thought of as a container of stories and tasks with a clear achievable end date.
Epics are usually planned on your roadmap which is why it’s really critical that it’s clear when an Epic is finished. This way, you know if you were successful or not. Try to avoid long-running, unfinishable Epics like ‘maintenance’ or 'refactoring.'
234
00:14:59,960 --> 00:15:04,570
Try to avoid long-running, unfinishable Epics like ‘maintenance’ or ‘refactoring.’
Once you’ve created some Epics using the Create Issue screen like we did back in minute 8:00 of this video, those Epics show up in your Backlog screen and this can be very helpful when planning and prioritizing.
By default, the Epics pane is collapsed but you can open it by clicking that little tab that says Epics just to the left of the list of Sprints in your Backlog.
The Epic pane here on the Jira Scrum Backlog screen allows you to do three things.
248
00:15:54,809 --> 00:15:57,869
do this, the Backlog gives you a very colorful look at the balance of work on
249
00:15:57,870 --> 00:16:02,120
your team by Epic. Don’t forget, each issue can only be in one Epic at a time.
Finally, on this screen, once your issues have been properly assigned, the Epic pane in JIRA allows you to easily look at the issues for one Epic at a time. You can do this simply by clicking the Epic at the left. Notice that, as I select each Epic, the backlog collapses down to only the issues from that Epic.
When you want to see the whole Backlog again, just click ‘All Issues’ at the top.
Now that we have our Epics all sorted out, it’s time to plan the next Sprint. Open the F Sprint on your Backlog, and you can see that it’s ready for us to add some issues. A moment ago we prioritized our Epics, so I’m going to grab these yellow tickets first.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9qYIteUA-1588486000055)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422023908539.png)]
That way, we make sure to address our highest priority work at the top of the Sprint.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lpubIov0-1588486000056)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422023939051.png)]Now that I’ve added 2 tickets, notice the Story Point total at the bottom of the Sprint, next to the line that says ‘Estimate.’
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ioem4fIy-1588486000057)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422024007019.png)]
If you’ve already Story-pointed your Issues during Sprint Planning, as I’ve done here, then you’ll see that the total accumulates as you add work.
Today, we’re going to pretend that, in my last 10 sprints, I’ve learned that my team can get about 15 story points done in a Sprint. I’m going to continue to add work until I hit that number. I’ll explain that more in a second.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ubmTGOa6-1588486000057)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422024423668.png)]
This number of Story Points that can be done in a Sprint is called my team’s Velocity. Once I hit this Story Point limit, my team is unlikely to get more work done beyond that, so I’m going to move on to the G sprint next.
There, I’ll continue to add tickets until I hit my 15-point limit again.
Notice here, in Sprint G, that I went to 17 points which is a little over my team’s velocity.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RgPIRKSy-1588486000058)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422024509646.png)]
That’s okay, but there’s a little bit of risk when you do this. Get as close as you can, and always make sure the team agrees with the Sprint commitment.
I’m going to pause here for a second to talk about Story Points.
When estimating in Agile, assign each ticket a story point of 1, 2, 3, 5, 8, or 13.
I skipped some of those numbers on purpose. These are the numbers in the Fibonacci sequence. In Agile, Fibonacci numbers are typically used,
Because when tasks are small, your ability to imagine exactly what you’ll do is fairly accurate. When the estimates are 1 or 2 these are actually usually somewhere around proportionately成比例的 reliable. The 2 really is twice as hard as the 1.
But as those tasks get bigger your ability to estimate exactly, perfectly gets worse and worse. Your error in estimation becomes greater and greater and at that scale the difference between a 12 or 13 or 14 is mostly irrelevant.
Fibonacci numbers map nicely to this error in estimation. And that makes it a good sequence to use for Story Pointing.
There’s one more important point. If your team is new at this, you’ll be pulling numbers out of the air for a bit. If one person on your team is estimating a 1-day-ish thing as 21 points, while others are estimating a 1-day-ish thing as 2 points then your team velocity won’t make any sense at all. You’ve got to find a way to calibrate校准.
If you have at least one person on your team that has done Story Pointing before, then use that person to help your team align on its estimates.
If your whole team is starting from scratch here though, try something like this. Heads up! Agile Aficionados are gonna hate me for this. But I swear it really is useful on new teams. If your whole team is starting from scratch without an agile expert, then remember this:
The smallest task or issue ever should be 2 to 3 hours and that should be one Story Point.
And your biggest task or issue estimate ever should be three days or 13 Story Points.
New teams without an experienced expert, can use these two fundamental truths(boundary points) to guide their pointing until they get the hang of it掌握它.
Now that you’ve prioritized your work and used Story Points to figure out what is realistic for the next 2 weeks, it’s time to start your Sprint.
You can start your Sprint by clicking the Start Sprint button at the top right of the Backlog Screen. Just enter a start date and an end date and the team will be ready to tackle the next iteration of your work.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1lCkEop5-1588486000058)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422030016839.png)]
After the Sprint has been started, from then on, you and your team will interact with the work everyday from the Board. Whether you’re Scrum or Kanban, the board in Jira is the primary screen your team will use to interact with their work. You can get to the Board for your project in Jira using that little icon at the left that looks like a three pane window.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T7PfHaM5-1588486000059)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422030152219.png)]
Agile Boards are designed to replicate, the original Agile practice of putting physical index cards on a wall next to the team. On the board in JIRA, tickets are shown as virtual cards and they move from left to right as they make their way through the Jira workflow. From ToDo, In Progress, to Done.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Zg5YTZUr-1588486000059)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422030409822.png)]
Workflows can be customized to be infinitely无穷地 more complex than this. But if you venture into workflow customization territory, try to make sure that the following things are always true.
First, all tasks in the project should go through all the steps of the workflow.
And second, users should be able to see ALL the columns of the workflow. So keep the number of steps to seven or less. A board usually shows a team tickets in a single project - although it is possible to combine multiple projects by editing the filter behind the board and making it more complex. But make sure that a single person on your team only needs to care about one project and one board in JIRA at a time. When a person has to straddle three different boards to get their work done, it’s impossible to prioritize across their pool of work, and you’ll quickly find that your JIRA will fall out of sync from what your team is actually doing.
For more on mastering Agile and customizing your JIRA experience to match the way your team works, check out my other YouTube videos on Building Great Software with Teams! Teamwork and collaboration合作 can be hard. Especially across offices and time zones. But Agile best practices can make it all a little easier. Jira is the Agile choice for some of the world’s greatest technology teams. But even if you’re using one of the other great tools out there: Asana, TFS, Trello, Monday, or one of the others; i’ve learned that by following some of the best practices outlined here in this video, your team can be one of the great ones too. That’s it for now. Thanks for watching.