Agile management - JIRA使用入門

Introduction

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.

ELements

Projects

• 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.

Types of Agile

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.

Kanban Agile

• The first flavor of Agile is known as Kanban. Kanban Agile is best for teams that are working on bugs or issues where most issues have a flexible - or more commonly an ‘as soon as possible’ (ASAP) delivery schedule. In Kanban, there’s a focus on rapid assignment and working in the right order and not as much on estimating projected completion dates for every piece of work.
  • Imagine you’re working on a team like a customer support or operations team in which the majority of your work comes from customer-submitted issues or tickets. New issues are reported frequently and some of them require an incredibly urgent turnaround. Other lower priority issues can be addressed on a lengthier timeline. The fluid nature of Kanban helps these teams achieve their need to react with varying speed at varying times.
  • In cases like this,
    • teams collect all the work that needs to be done,
    • they put the work in the right order,
    • and they assign it and complete the work as fast as they can.
  • That’s Kanban.
  • To create a new Kanban project, just name your new project and then click the change link to select the Kanban workflow template from the list. That’s it. Now you have a Kanban project.

Scrum Agile

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.

Agile Tasks

• a single Agile task should take a least a few hours to complete
• a single Agile task should not take more than 3 days to complete
  • with this as a guidline you can ensure that your team can reprioritize at least twice per week if , and when you need to
  • this also helps to make sure that every team member is always less than 72 hours from getting from getting the next thing done.
• As you beigin to master Agile, try making the maximum amount of time for a task 1 day to complete.
  • that way, in every single stand-up meeting, your team members will always have the ability to finish the thing that they say they’re work on for the day.

Issue Type

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.

• Stories are usually used by Product Managers to deccribe planned work for a specific feature of a product.
  • For example, as an user, I need the ability to delete an element in a list.
• Tasks are typically used by any team members to describe other planned, non-story work.
  • Tasks can include literally anything - like: “Create the new database for the Customer Profile Module.”
• Bugs can be used to explicitly call out unplanned work. This is helpful when you are trying, as a team, to improve your overall quality.
• An Epic is a collection of Stories & Tasks arranged together to achieve some specific, notworthy outcome.
  • In theory, an Epic is a container of tasks and stories. In JIRA, this is mostly true.
  • Revise the platform User Login to incorporate 2-factor authentication.
    
• Sometimes it behaves a little more like a label. But either way, Epics are important and useful.
• Once you have a few Epics created, you can then add Tasks and Stories to them in the backlog view.
  • In scrum planning, it’s a good idea to start by defining your Epics at the beginning of a planning session. 建議在開始的時候就創建一些Epics
  • Then, after you prioritize the epics, build out the stories that complete them. 在給創建好的Epics排好序之後，再在這些Epic裏面創建Stories去完成他們。

Agile Boards in the JIRA backlog

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.

• The story points field is useful when trying to estimate work during Scrum planning.

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.

  • With labels, users can choose from existing labels or just make their own labels on-the-fly 即時 while editing a ticket. This enables very dynamic and Agile classification because users can adapt it on the fly as they need to.
  • We can often use lables to help us differentiate between tickets for each of my Scrum teams.
    • For instance, “Front-end” versus “Back-end”, or “RedTeam” versus “GreenTeam” versus “BlueTeam”.

• Components are also tags.

  • In contrast, while exsiting Components can be added to a ticket by any user with edit privileges, New components must be created by an administrator in the settings section for each project.
  • We often use components to help us differentiate between modules with my products.
    • For instance, User Profile Module, Metrics Dashboard Module, Machine Learning Engine, etc.

• 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.

• In kanban projects, teams tackle the work as it comes in. There is no Backlog in Kanban - for Kanban projects, you can jump ahead to the section on Boards.
• The scrum Backlog appears at the bottom of your Backlog view in JIRA. You can get to this view once you’ve selected your project, using the icon over at the left that looks like a Jenga tower with one piece being pulled out of it.

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.

• As we discussed briefly before, in the Scrum style of Agile, teams break their work up into iterative batches called Sprints. This helps teams to set clear and iterative milestones for their work. It creates clear and controlled opportunities for teams to pivot(以…爲中心旋轉) and reprioritize as they learn new things, while at the same time, driving the work toward completion with planning, realistic estimation, and firm milestones.
  • A Sprint has a start date and an end date.
  • Sprints are often two weeks long.
    • It’s often difficult to complete substantial(重大的；基本的) features in a single week, and since the team should commit to completion of the work in a Sprint at its start, it’s hard to commit to things at a granular level once you get beyond two weeks or so.
  • Also, while a Sprint is active you shouldn’t add new work to the active sprint. Instead, put new work in one of the upcoming sprints.

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.

• First, you can drag Epics up and down in order to create clear, visual prioritization for your work. I’m going to grab the Production Issues from Sprint E Epic and drag it to the top of the list because those issues outrank any of the others. The others are good like they are for now.
• Next, I mentioned earlier that an Epic is a container of issues. Now it’s time to fill the container. We can use this screen to quickly and visually drag each issue from the Backlog over into its respective Epic. You can see that, as I do this, the Backlog gives you a very colorful look at the balance of work on your team by Epic. Don’t forget, each issue can only be in one Epic at a time.
  • [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-8f0v9QLK-1588486000053)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422023302153.png)]

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.

  • [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-gfWaSD9G-1588486000054)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422023448110.png)]

  When you want to see the whole Backlog again, just click ‘All Issues’ at the top.

  • [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-SfJTTGhg-1588486000055)(/Users/xuzhijie/Library/Application Support/typora-user-images/image-20200422023523880.png)]

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.

• In order to plan the right amount of work in a Sprint. It’s important to estimate that work somehow.
• As mere mortals凡人, our ability to estimate hours accurately is pretty poor. So in Agile, we estimate work using Story Points.
• Story Points help us to overcome the inherent uncertainty of estimating, while still creating a useful quantifier for the items in our backlog.
• Story Points are just a relative measure of complexity - a 13 is way harder than a 5. That’s it!

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.