A New Introduction to Jira & Agile Project Management

A New Introduction to Jira & Agile Project Management


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. First let’s talk about 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. 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. 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. 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.
The other flavor of Agile is called Scrum. 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. First, a single Agile task should take
you at least a few hours to complete. This helps to minimize the amount of
energy you spend tracking things that are done very, very quickly. This also
ensures that the critical and high-priority items aren’t lost in a sea
of items that don’t require as much cross-team visibility. Next, a single
Agile task should not take more than three days to complete. With this as a
guideline 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 the next thing done. As you begin to
master this, try making the maximum amount of time one 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 working on for the day. Let’s
create another new ticket now so we can take a little closer look at the Issue
Type field. When you create new tickets, you have an option called Issue Type.
This allows you to distinguish between the different types of work for your
team. Your options are Stories, Tasks, and Bugs. Epics 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. I’ll talk about that more in a later
section. 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 of these as synonyms. When you want to get a little more granular, you can break it down like this. Stories are
usually used by Product Managers to describe planned work for a specific
feature of a product. For example: “As a user, I need the ability to delete an
element in a list.” That’s a story. 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.” And finally, you
can use Bugs in order to explicitly call out unplanned work. This is helpful when
you are trying, as a team, to improve your overall quality. Here’s one that I bet
some of you have seen before: “The leading 0 from Northeast U.S. zip codes is not
showing as expected.” There’s one more useful issue type the
Epic. In Agile, an Epic is a collection of Stories and Tasks arranged together
to achieve some specific noteworthy outcome. For example, “Revise the platform user login to incorporate two-factor authentication.” or “Add multi-language
support for the customer module.” In theory, an Epic is a container of tasks
and stories. In JIRA, this is mostly true. Sometimes it behaves a little more like
a label. But either way, Epics are important and useful. You can create new Epics in JIRA using the Create Issue button in the same way that you create
new stories and tasks. 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. Then,
after you prioritize the epics, build out the stories that complete them. If you’re
following along in your own JIRA, create a few Epics now. We’ll come back to this
a little later in this video when we talk about Agile boards in the JIRA
backlog. Now, we’re ready to dig in a little deeper to the issue details. In
addition to the basics, there are a few attributes that will come in really
handy especially as the list of tickets for your team gets large. Before we can
use them, we need to enable the additional fields on the create issue
screen. Here, I’ll show you what I mean. Click the Create issue + sign in the
left nav, as we did before. Now, 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. Today, I’m just going to add Labels and Components, because we’re
going to talk about some of their differences next. While we’re here,
I want to add one more field that will come in handy later: the story points
field. Sadly, story points is not on the ready-to-add fields list. But still, Jira makes adding this additional field fairly easy. If you’re looking for this field, or any other field that 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 looking for, select it. The where’s-my-field wizard
will give you an explanation of why this field isn’t there… with so many words…
lots and lots of words. But just scroll down. It’s most likely this. The [blank]
field is not included in the [blank] issue screen. If that’s the issue,
notice the line that says: “to solve this problem, go to…” And then just 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. I’ll explain everything there in another
video. We’re looking at the available field list for the default issue screen
for our project. 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 fields 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 followed my advice and 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. With labels, users can choose from existing
labels or just make their own labels on the fly. This enables very dynamic and
Agile classification because your users can adapt it on the fly as they need to.
I often use labels to help me differentiate between tickets for each
of my Scrum teams. For instance, Front-end versus Back-end, or RedTeam versus GreenTeam versus BlueTeam. In contrast, while existing 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. I often use components
to help me differentiate between modules within 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. With what we’ve discussed so
far, you should have everything you need to capture all your work in JIRA. But
that’s only half the battle. Now we’re going to talk about 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 may remember from earlier in this video, that 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 make this 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.’ 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. 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. That way, we make sure to
address our highest priority work at the top of the Sprint. 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.’ 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. 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. 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 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. 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.
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. 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.

100 thoughts to “A New Introduction to Jira & Agile Project Management”

  1. best jira/agile intro video I have watched on youtube. Simple to understand and to follow. Thanks for sharing. God bless.

  2. This was a really great explanation. Great job demonstrating features as your lecture addressed them. Great production quality on the video. Audio could use a little improvement, but wasn't terrible.

  3. Too robotic for me, it feels like a machine talking to me. I prefer the first version of this video since I remember it better.

  4. Dan, thanks so much for posting this video. It is a lot easier for me to understand than your original. You structured the information in a way that was a lot more conducive for me to process it effectively.

  5. Big thanks for the video! I like your way of explaining, but the music is superfluous and takes attention away from the subject at hand.

  6. While I was searching for the agile project management videos, I found out that there are not too many freshly published content. Majority of videos are 2, 3, 4 or 5 years old. For sure, there must be some new and interesting things that could be said about Agile practices, like you did in this video. Nice.

  7. Hi Dan, I'm just starting to learn about Jira and Agile PM and your video was the first I came across. Do you have any other videos or could you recommend other webinars that would help me get a greater grasp beyond this intro?

  8. This video was very helpful!  I really appreciate you taking the time out for people who are new to Jira!  Thank you.

  9. Dan, I'm 6 minutes into the video with 22+ minutes to go, and my brain is increasingly unable to process what you are saying because of the music. Can you create a music-free version for the many commenters who want your valuable information with no music track? I have this same issue with many spoken word recordings. It looks like I'm not alone. I am hearing it as foreground music, not background at all. Thanks!

  10. Loved the video and the background music. The background music keeps you on the beat. But some people have difficulty understanding the beat and becomes annoying to them 🙂

  11. The background music is totally unnecesary and actually distracting. Besides, it is loud enough to be a nuisance.
    What's with this having to add background music to every tutorial on youtube? If we wanted to listen to music we would be watching a different video and not this tutorial. It is a shame because the contents of the video is interesting.
    I do appreciate the effort and time you spent on its making. This is still a good video despite the music.Thank you very much.

  12. @Dan, thanks for making this video. Came to this from your older 101 video. It is quite crisp and precise – much appreciated. Would be very interested if you were to ever make a video on how to adapt the usage of JIRA for SAFe but focussing not only on how the SCRUM or Kanban team uses it, but how SAFe Solution Manager and SAFe Product Manager may use it! I'd imagine it as a having to have a hierarchy of Epics, or creating custom labels — reflecting the onion-shell analogy of SAFe's layering of concerns.

  13. Thank you for the video, I am starting in a new company that uses Jira and you helped me understand how to use it. (the only complain I have is the music is a bit too loud, but great video, thank you)

  14. Thank you, this video is excellent! Helped me figure out Jira and also understand best practices in estimation.

  15. Nice video and very eloquent presentation. I now have a substantive idea of how this works.
    Regarding the background music, I did not really notice it’s disruption until I read the comments…..😄
    Good job anyways.

  16. Thank you for this. Great information shared. The music in the background is a bit loud – just some feedback. I had to really try to ignore the music. Maybe have the volume turned down? Or omit it?

  17. A most excellent video in getting started with Jira with basic agile project management principles.

  18. It is hard to understand with the music in the background. Your voice level is almost same as music level

  19. Finally something in Proper English. I think youtube needs to take action on some folks with very bad English accents and very bad sound quality videos that are just frustrating when you are looking for a video.

  20. I'm excited to finally have the final segment of my #DisruptiveProducts talk from #SXSW2019. In this segment I cover why you need #neuralnetworks and how they work in simple easy-to-understand example using the audience & a deck of cards. Let me know what you think in the comments. https://www.youtube.com/watch?v=sizZ4cM2HFE

  21. This tutorial almost answered all my question in only 22 mins which is amazing.I can't expect anything better than this..Thank you very much for all your efforts you put in and hard work for helping others..!!

  22. A really great an succinct high level summary for agile in Jira. Could do with lowering the volume of the background music though.

  23. Great Video!

    I wonder if i can create an Epic, under it Story, then Tasks and Test Cases?

    Your feedback is greatly appreciated in advance.

  24. From 20:27 in the board, there should be Pending and Not OK columns for a task because sometimes the task isn't done well or sometimes it is done for some parts and it is only completed when other task is finished

  25. It’s informative…but it’s spoken at fast pace and the background music doesn’t help…. it’s distracting…

  26. Nicely explained, thanks for that but I find it super fast and not enough time provided to even see what you are showing on the screen. May have to slowdown the fps.

  27. This is very well-done video. Clear, easy to understand explanations. Moves along at a good pace. Speaker has an excellent voice and inflection, making it much easier to understand.

  28. This an excellent introduction to JIRA, however, the background music is very disturbing and unnecessary. If, you need music to fill in then please rerecord it with much lower volume. Thanks

  29. Hello fellows, I'm a web developer who is really eager to create a project management tool that is scalable and easy to understand and use! You could really help that happen by sharing what your needs are 🙂 I have described what I currently have in mind below, thanks for reading!
    I am working for a company that uses Jira for managing tasks, releases, tests, etc. I believe Jira is really badly organized due to its flat structure of tasks(and not only) – they are all in the same place and the only way to find something is by using an advanced search, specifying status, type, some keywords, labels, etc.. I know there are far better tools than Jira nowadays, ClickUp, Asana and many more. However, I was not able to find a nice tool which allows your project to scale infinitely by utilizing a simple abstract tree structure. That is,

    – your project is a root node and it may have many child nodes
    – each child node can have child nodes and so on
    – each node is either a topic or a task
    – tasks may still have subtopics and subtasks
    – you can create custom roles and give access to a specific set of nodes and their subtree(for great flexibility when working with freelancers for example)
    – you can follow a certain set of nodes and receive notifications for any changes in them so that you don't accidentally miss something and at the same time you will not receive spam from topics you are not interested in (for example if I am a front-ender, I would not be interested in back-end design decisions or marketing/business strategies)
    – you can have a kanban board or a Gantt chart generated for a specific node(if a team/member is working only on a given topic at the moment which allows for better focus)
    – users can navigate through the tree as if exploring folders(topics) and files(tasks). You have a 2-column layout, the tree is on the left and the preview of the currently selected node is on the right. Clicking once on a topic/task previews it and if you click twice -> you enter it and see its child topics and tasks.

    Let's hope this sums up the idea well. What do you think? It is complex in order to accommodate complex projects and employee structures but is it TOO complex? Would you use it and if not, why? What else would you like to see?

    Thank you so much for your opinions and suggestions!! 🙂

  30. first time watching jira video and i understood most of it..now i will watch again to understand all of it ..its jira in a capsule ! thanks 🙂

  31. I'm at work, i've got no tasks and slept 4 hours. At least I used time in a useful way since I cannot watch Netflix or take a nap on my desk. Thanks for the vid. Never used Jira nor I have it on my pc but I tink I won't start from zero if I'l ever need to use it.

  32. Hi Dan, this was one of the best videos I've ever seen. Amazing work, thank you! Awesome tutorial on Jira, and it turned out to be a very nice overview of Scrum and Kanban as well. Absolutely loved it. Pacing, content and explanation was also great. Keep up the great work!

Leave a Reply

Your email address will not be published. Required fields are marked *