Trying to learn Jira & Agile at the same time? I got you!
Sometimes, trying to learn two things at once, like Jira and Agile, can feel like walking and chewing gum at the same time, in other words, a very sticky situation!
But, it doesn’t have to be that way! I wrote this article to give you a quick overview of Scrum and Kanban, two popular Agile frameworks. I will share plenty of resources so you can learn more. Ready? Grab your bubble gum and let’s do this!
|
These two resources can be a great place to start, providing an overview of both options:
Now, let’s dive into more detail! |
Scrum
Scrum is an Agile framework based on planning work in small increments, called sprints.
-
Sprints can be 1 to 4 weeks long, with 1 or 2 weeks being the most typical.
-
All the work for the project, referred to as stories, is created in a backlog that’s ranked from most important to least important.
-
Teams will pull stories from the top of the backlog into their next sprint, based on estimates called story points.
Story points are not an indication of how long it will take to complete the story. Why not, you ask? Because software development isn’t like baking a cake at 350° and we can just read the recipe (or the back of the Betty Crocker box!) to see how long it will take.
Humans are really, really bad at estimating but we are good at comparisons! Let me illustrate this with a quick example. Let’s say we needed to file the two stacks of paper, below:
|
Stack 1 |
Stack 2 |
|---|---|
|
|
 |
If I asked how long it would take to file stack 1 and how long to file stack 2, how confident would you feel in that estimate? 😅
But, what if I instead asked which would take longer to file, stack 1 or stack 2?
I’m guessing everyone would say stack 2 would take more time, and feel very confident about that answer. (Let me know in the comments if you disagree! Also, let me know if you have similar-looking piles of paper to file sitting in your office! 😜)
The same concept applies to estimating development work via story points. We compare stories to each other and give higher story points to work that is more complex and/or has more risk or uncertainty. We give fewer points to work that is more straightforward.
So, let’s go back to those stacks of paper. If we say that the first stack is one story point, we can use that as our baseline. The other stack is somewhere between two and three times the complexity, so let’s play it safe and call the second stack a three-point story.
Over time, teams will get very good at consistently estimating their work in story points.
Start the sprint! 🚦
All sprints start with a planning meeting to discuss the stories at the top of the backlog.
-
The team estimates the stories and will use past sprints to guide how many story points are realistic for this sprint.
Run the sprint! 🏃
During the sprint, the team will have a quick ~10-minute meeting each day called a stand-up.
-
Be careful not to let your daily stand-ups turn into project status meetings. The purpose is just to let the team coordinate that day’s work and identify any potential blockers.
End the sprint! 🏁
At the end of the sprint, the team will review what they accomplished, plan the next sprint, and the cycle continues.
Scrum is often represented by a diagram like this:
|
Want to learn more about all things scrum? Here are some great resources to check out:
If you’d like to go even deeper, consider searching for Scrum Master training courses in your area. Scrum Master training, with or without certification, will give you a more in-depth, hands-on learning experience. |
Kanban
Kanban is another popular Agile framework. While scrum is based on planning and completing work via small time segments, kanban is all about flow.
-
Instead of estimating all work, tasks should be broken down so that they’re all roughly the same size/level of complexity.
-
Teams measure cycle time and lead time (see the screenshot below), which is then used to predict completion.
-
If you know that it typically takes X amount of time for tasks to move from start to finish (cycle time) or it takes Y amount of time from when tasks are added to the board to be finished (lead time), then you can multiply that by the number of cards and get an estimate of when your work will be completed.
So, let’s go back to our paper stacks. In our scrum example, the two paper stacks were definitely NOT the same size, so we’ve got some work to do. We need to break the large stack down into multiple, smaller stacks so that our To Do column would then look like this:
|
To Do: |
|---|
|
Work item 1 |
|
Work item 2 |
|
Work item 3 |
|
Work item 4 |
If it typically takes us one week to move four items from In Progress to Done once we start work (cycle time) then we should be done filing one week from when we start. If it typically takes the team 2 weeks to start new work once added to the list, then it will be 3 weeks from when the paper stacks are added to our To Do column (lead time) until we are done.
It sounds easy, right? Yes and no. The process is simple, and sometimes teams are drawn to kanban because there’s fewer steps and fewer meetings than scrum. Just know that kanban requires a high level of experience and discipline. Those scrum meetings are there to keep the team on-track and by planning in small increments, the team hopefully never falls too far behind. If they do, they can more easily recognize and mitigate schedules. With Kanban, teams need to make sure they’re doing all of the following:
-
Sizing work to all be about the same size
-
Limiting work in progress (WIP)
-
Focusing on continuous delivery (sometimes easier said than done!)
-
Ensuring that cycle and lead times remain consistent
|
Want to learn more about all things kanban? Here are some great resources to check out:
|
Putting Jira and Agile together:
Hopefully, this article has given you the insights you need to decide whether to use scrum or kanban for your team. So, what’s next?
Hop into Jira, create a project, and start creating stories… Before you do, though, there’s just one more decision to be made:
|
As Columbo would say: "Just one more thing…" You will be asked if you want to create a team- or company-managed project. For that decision, please see the following:
|
Join me in an upcoming office hours to talk all things Agile! Ready? Let’s goooooooo:
Was this helpful?
Thanks!
Peggy Graham
0 comments