Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained

0:00 [Music] hello everyone this is eric

0:05 from invensis learning welcome to our youtube

0:08 channel [Music] in this tutorial session we are going to learn

0:16 everything about agile methodology before we get started let us quickly go

0:21 through the agenda as you can see on the screen we will

0:24 begin by knowing a little bit about the history of agile we

0:27 will also take a look at the methodologies that were used before

0:30 the agile development model then we will discuss the agile manifesto about

0:34 the values and the principles present in it post that we will

0:37 discuss what exactly is agile its advantages and disadvantages and its

0:41 components then we will talk about the people who are part

0:44 of the agile team the agile life cycle and the different metrics

0:47 that agile teams use then we

0:49 will discuss various agile methodologies best practices

0:52 and tools finally we will conclude this session by discussing how

0:56 to use the jira tool to manage an agile project let's get started

1:01 whether or not you recognize its name you have probably encountered agile

1:04 or at least companies that use it in the past decade agile has

1:08 swept across industries literally leading everyone from tech giants to startups

1:12 to work differently it may seem like another meaningless corporate buzzword used

1:16 by project management types but it's actually a very specific philosophy one

1:21 that is outlined in the four bullet 68 word documents signed at snowbird

1:25 but are you aware of how agile movement happened did it happen

1:29 by chance or was it inevitable how was the name agile selected

1:33 let's take a brief look at the history of agile in the late

1:36 1990s the personal computer explosion happened with that almost everyone gained

1:41 access to modern computing the explosion

1:44 of personal computing meant that product

1:45 and software development had to undergo changes to meet the increasing consumer

1:49 demands software development faced a bit of a crisis known as the application

1:54 development crisis or application delivery lag industry experts of that time

1:58 estimated a three years time gap between a business need and actual

2:01 application obviously within this time lag

2:04 requirement systems and even entire businesses

2:07 were likely to change that meant that projects ended up being cancelled

2:11 part way through some of those that were completed didn't meet all

2:14 the businesses current needs even if the project's original objectives were met

2:18 throughout the world software development teams

2:20 started getting frustrated people began thinking

2:23 the way we have been building software just isn't working for us

2:27 we've got to come up with something different a lot of attempts

2:30 were made to implement and promote iterative software development but the entire

2:34 decade was dominated by waterfall methods now that might be a new

2:38 term for a few of you out there so let me brief

2:41 you on it before agile took hold the software was built through

2:45 waterfall development a process where something

2:47 was coded entirely from detailed guides

2:50 descriptions and manuals in simple terms think of it as a slow

2:54 trickling stage by stage process it works something like this someone would

2:59 come up with a piece of software they'd like built before so

3:02 much as a line of code is written the creators write out

3:05 what they want to build and how in a series of long

3:07 detailed plans they craft what's called

3:09 a requirements document where they outline

3:11 everything they want the software to do projects then flow downstream from stage

3:16 to stage team to team until they reach completion at the very

3:20 end the entire new piece of software is tested given back

3:23 to the customer and sent out the door this approach may sound

3:26 fine when you know what you want to build but it can be

3:28 too restrictive for some projects where

3:30 requirements keep changing also waterfall prioritized

3:34 bringing a complete product to market meaning it could take years before

3:38 teams finish the project at hand and of course waiting until

3:41 the end of a project to test the whole thing can be problematic

3:44 if you catch a bug at the last stage it can be

3:47 messy or even fatal to try to go back and fix it

3:50 at times some software projects would get stuck and simply never ship

3:54 most importantly the waterfall methodology focuses very little on the end user

3:58 or client involved with a project frustrated with these seemingly unproductive

4:03 software development activities software developers

4:06 and other practitioners wanted to create processes

4:08 that would give them more flexibility and actually allow them to ship

4:11 software on time while major and highly visible projects often used a strict

4:16 waterfall model alternatives were lurking in the background and thus we saw

4:20 the introduction of development methods like

4:22 scrum crystal framework extreme programming dsdm

4:25 feature driven development and pragmatic programming

4:28 some of these processes like scrum

4:30 and extreme programming xp were called light or lightweight processes but no

4:35 one subset had really caught on so in 2001 people who

4:39 created these methodologies and few others decided to join the forces who

4:44 would have thought a software revolution would happen at snowbird utah

4:47 but it was here nestled in the white-capped mountains at a ski resort

4:51 that a group of software rebels gathered in 2001 to frame

4:54 and sign one of the most important documents in its industry's history they

4:58 did some skiing and discussed how they could speed up development times

5:01 in order to bring new software to market faster there were a lot

5:05 of things that they didn't agree upon but there were a few

5:07 things that they were to agree upon and then ended up becoming

5:10 manifesto for agile software development and so the agile manifesto was born

5:15 with four values and twelve principles but what were those four values

5:20 why should you care let's take a look individuals and interactions

5:24 over processes and tools in the past a lot of software teams

5:28 would concentrate on having the best possible tools and process to build

5:31 the software the agile manifesto suggests that it's the team you work

5:35 with and the way you work together that determines success in other

5:39 words agile encourages humans to leverage the skills that only we as humans

5:42 have emotional intelligence creative problem solving

5:46 and critical thinking working software over

5:49 documentation like i mentioned when discussing

5:52 the waterfall model traditional software development

5:54 processes often focus on extensive documentation even before a line of code

5:58 is written however in agile software development getting software in the hands

6:03 of customers is the highest priority with that said it's important

6:06 to note that documentation in itself is not a bad thing as long

6:09 as you don't overdo it customer collaboration over contract negotiation once

6:15 upon a time contracts were king they dictated what to be delivered

6:19 in the end which left a lot of room for mismatched expectations

6:23 the agile approach gives importance to customer

6:25 centric product development practices over product

6:27 centric approaches according to the agile manifesto the focus should be

6:31 on continuous development responding to change

6:34 over following a plan can you imagine

6:37 a time where you would draw up a road map and it

6:39 would never have to be changed at all well in the past

6:42 that's exactly what happened there was no room to incorporate new requirements

6:47 needs and requirements are always shifting

6:49 and priorities are never static that's

6:51 why the agile manifesto encourages frequent

6:54 reviewing and retooling of current plans

6:56 based on new information that the team is continually gathering and analyzing

7:00 so your roadmap is no longer a static document it becomes

7:03 a dynamic strategy so these are the four epic rules that were

7:07 drafted at the ski resort with that said it's important to note

7:11 that the agile manifesto ends by noting that all of the things

7:13 mentioned are important just that some things must be prioritized over others

7:18 the group finished the manifesto during the retreat they spent the rest

7:22 of the time working on the 12 principles behind the new document

7:24 and while skiing let me walk you through these 12 principles quickly

7:29 the first principle says our highest priority is to satisfy the customer

7:33 through early and continuous delivery

7:35 of valuable software the second principle states

7:38 welcome changing requirements even late

7:40 in development agile processes harness change

7:43 for the customer's competitive advantage the next

7:46 principle is deliver working software frequently

7:49 from a couple of weeks to a couple of months with a preference

7:52 to the shorter time scale another

7:54 principle states business people and developers

7:56 must work together daily throughout

7:58 the project there's also build projects around

8:00 motivated individuals give them the environment and support they need and trust

8:05 them to get the job done and there's also the principle

8:08 that states the most efficient and effective method of information to and within

8:12 a development is face-to-face conversation one

8:14 of the principles says working software

8:16 is the primary measure of progress the ninth principle says the sponsors

8:21 developers and users should be able to maintain a constant pace indefinitely

8:25 there's another saying continuous attention

8:27 to technical excellence and good design enhances

8:30 agility simplicity the art of maximizing the amount of work not done

8:34 is essential is yet another principle one of the last principles is

8:38 that the best architectures requirements

8:40 and designs emerge from self-organizing teams finally

8:44 there's the last principle that says at regular intervals the team reflects

8:48 on how to become more effective then tunes and adjusts its behavior

8:51 accordingly these four values and 12 principles continue to guide the agile

8:56 methodology used by teams today after the authors got back from snowbird

9:00 they were ready for the next chapter in the history of agile

9:03 that is convincing the world of the value of everything they laid

9:06 out in the agile manifesto to help spread the word about agile

9:09 manifesto they decided to create a more permanent organization and so

9:13 the agile alliance was born the agile

9:16 alliance is a non-profit organization where

9:18 people can share information about agile provide resources for teams looking

9:21 to adopt the agile methodology explore and share ideas and experiences as agile

9:27 took off the role of the agile alliance expanded in 2003

9:31 the now formal agile alliance returned to utah for the first annual agile

9:35 conference this annual conference happens every year even now as agile became

9:40 more widely known an ecosystem formed this ecosystem included people who were

9:45 doing agile and other people

9:46 and organizations who helped them through consulting

9:48 training frameworks and tools in the 2010s agile picked up a new

9:53 stream but between 2012 and 2015 agile surpassed the 50 mark

9:58 in adoption truly taking the development world by storm in 2017 we saw

10:03 the first succinct definition of agile testing and that's the agile

10:07 software development methodology that we all use today you know there is

10:11 a saying success has many fathers in that sense agile innovation has

10:15 a colorful heritage we have talked so much about the history of agile

10:19 but what exactly is agile according to the agile alliance agile is

10:23 a mindset a philosophy informed by the values contained in the agile

10:27 manifesto and the 12 principles behind the agile manifesto these values

10:31 and principles together provide guidance on how to create and respond to changes

10:35 and deal with uncertainty with ease so when you think of agile

10:38 as a mindset that can be applied to other activities as well

10:41 not just project management or software

10:43 development unlike the waterfall model agile

10:46 methodology emphasizes iterative development or building

10:49 software in pieces by that i

10:51 mean you break down complex projects into small manageable goals you are

10:56 working towards these goals while adding new goals based on the requirements

10:59 and customer feedback they do this by breaking up the traditionally

11:03 long delivery cycle into shorter periods

11:05 called sprints or iterations the iterations

11:08 provide the cadence for delivering a working product to customers get

11:11 their feedback and make changes accordingly

11:14 each of these iterations is a project

11:16 in miniature it has a backlog or what you know as a requirement

11:19 doc and consists of design implementation testing and deployment stages within

11:24 the predefined scope of work at the end of each sprint

11:27 a potentially shippable product increment is

11:29 delivered thus with every aeration new features

11:32 are added to the product which results in the gradual project growth

11:36 usually agile software development consists

11:38 of small self-organizing teams of software developers

11:41 and business representatives regularly meeting

11:43 in person throughout the software development life

11:45 cycle agile is an umbrella term for several iterative and incremental software

11:50 development approaches the most popular agile

11:53 frameworks include scrum extreme programming lean

11:56 crystal feature driven development and many others while each of these has its

12:00 own unique qualities they all incorporate

12:02 the principles of agile when developing

12:04 a product each has its own character that imbues it with strengths

12:07 and weaknesses by that i mean all these approaches are fundamentally iterative

12:12 incremental and adaptive apart from the lightweight approaches agile can also be

12:16 applied at scale for that we have frameworks such as scaled

12:19 agile framework dsdm and others which we can discuss later among all

12:24 of the agile variations scrum is by far the most popular and widely

12:28 adopted agile methodology for now i am just listing them later after

12:33 covering certain other topics let's discuss

12:35 each of these methodologies in detail

12:38 so by now you might be able to comfortably point out

12:40 the key differences between waterfall and agile models let us discuss the key

12:44 differences between these two methodologies or in general how agile is different

12:48 from traditional development approaches here

12:51 we go the waterfall methodology incorporates

12:54 a stepwise approach to project development

12:56 the project's progress flows downward through all

12:59 the phases similar to a waterfall whereas in agile all the phases

13:03 are repeated in every iteration in the waterfall model you need to finalize

13:07 the requirements before initiating development

13:10 activities whereas in agile changes are

13:12 welcomed at all stages so it is a flexible approach the waterfall

13:17 model has poor visibility compared to agile methodology because in the waterfall

13:22 model working software is not produced until it reaches the last phase

13:26 one more difference between waterfall and agile is their individual approach

13:30 towards testing and quality according

13:32 to agile testing is usually performed concurrently

13:34 with the development phase in waterfall the testing phase comes after the build

13:39 phase the waterfall team is a very structured unit with a project

13:43 manager leading the processes most of the team members have well-defined roles

13:47 and only work on what they're asked to do in the agile

13:50 approach most of the team members are self-sufficient and cross-functional while

13:54 there's a product owner and project manager guiding the team they're expected

13:57 to be fairly self-sufficient but the question is who do you determine

14:01 which methodology is right for you when looking at waterfall versus agile

14:05 frameworks you need to think of is the size of your project

14:09 short and simple or will it be better to divide it up is

14:12 your team very structured or is it filled with cross-functional members do

14:16 your clients want to actively be a part of your project process

14:20 does the project have fixed deliverables or is it very flexible there

14:24 are a number of factors that should be considered before a methodology

14:27 is adopted as you can see on the screen we've summed them

14:30 up to help you decide which is more suitable for your project

14:34 now that you are aware of what exactly agile methodology is i

14:37 am sure you can point out a few benefits yourself let us

14:40 go through some of the compelling reasons to consider agile improve

14:44 stakeholder engagement in agile the customer

14:47 is always involved in the decision-making

14:49 process which leads to greater customer retention by keeping the customer

14:53 in the loop and making changes according to their feedback you deliver value

14:56 to the customer and ensure that the final product is truly according

14:59 to their requirements superior quality product

15:03 by breaking down the project into manageable

15:05 units the project team can focus on high quality development testing

15:09 and collaboration the flexibility of the agile

15:12 method allows project teams to respond to customer reactions and constantly

15:15 improve the product improve transparency agile

15:19 is highly transparent everyone from stakeholders

15:22 to the development team knows what's

15:23 getting done what's not and who is making decisions when the entire

15:27 team understands the big picture projects tend to move forward faster early

15:31 and predictable delivery by using time boxed fixed schedule sprints of one

15:36 to four weeks new features are delivered very quickly and frequently

15:39 with a high level of predictability

15:42 this also provides the opportunity to release

15:44 or beta test the software earlier than planned if there is sufficient business

15:48 value predictable costs and schedule since sprints have a fixed timeline

15:52 the cost is predictable and limited to the amount of work that can

15:55 be performed by the team in that time allows for change

15:59 by creating smaller iterations the team is able to focus on providing value

16:03 without needing to get all the requirements up front there is

16:06 an opportunity to constantly refine

16:08 and re-prioritize the overall product backlog new

16:11 or changed backlog items can be planned for the next iteration providing

16:15 the opportunity to introduce changes within a few weeks acute focus on business

16:19 value agile methods ensure that at any given time the project team

16:23 is focused on delivering working software

16:26 the product backlog is prioritized based

16:28 according to the customer's demand this way the team can deliver

16:31 the features that provide the most

16:33 business value better control over the project

16:36 agile allows managers to have better control over the project due

16:39 to its transparency feedback integration and quality

16:42 control features risk analysis with increased

16:46 visibility predicting risks and coming up

16:48 with effective mitigation plans becomes easier

16:51 agile works in small sprints that focus on continuous delivery there is

16:55 always a small part that can be salvaged and used in the future

16:58 even if a particular approach doesn't go as planned improve team

17:02 morale as agile teams are self-organized

17:05 and self-managing they have increased autonomy

17:07 and authority over their decisions the project

17:10 manager shields the team from interference

17:12 from sponsors and management these are just some of the benefits

17:15 businesses are realizing agile not only

17:18 provides benefits to the development team

17:20 but also provides a number of important business benefits to the clients

17:23 as well who uses agile in real world more firms than you think

17:28 well let us check out some real-life implementations of agile then sky

17:33 sky group limited is a british

17:34 media and telecommunications conglomerate which is

17:37 a subsidiary of comcast and headquartered in london england for more than

17:41 eight years sky was using the same old classic method of defined

17:45 design and deliver it was fine at the start but after

17:48 a few years the employees started complaining that the process was slow

17:52 to implement and too top down they wanted to challenge ourselves to help

17:55 the organization learn without resorting

17:56 to traditional means hence instead of following

17:59 the traditional method and waiting for results tracy director of people

18:03 experience at sky decided to find her resolutions in an agile way

18:07 by embracing an agile mindset tracy and her team have not only

18:11 radically redesigned their own team structure

18:13 and operative model but have revolutionized

18:15 sky's people practices and learning culture lonely planet lonely planet is

18:20 a large travel guide book publisher founded in 1972 lonely planet is

18:24 a publisher of travel books and has sold more than 120 million

18:28 copies its popular travel app has more than 10 million downloads the lonely

18:33 planet legal team plays a vital role in the organization initially

18:37 the legal team was facing several challenges the legal team was commonly working

18:42 late sometimes until midnight this was

18:44 beginning to cause burnout and frustration

18:47 job satisfaction was waning the lack of transparency of priorities of work

18:51 being done by the team led their clients to generally assume they

18:54 were not working on anything as important as their need for a non-disclosure

18:57 agreement for all these reasons

18:59 agile seems counterintuitive the fast-paced nature

19:02 of agile does not sit well with the perfectionism needed in the legal

19:05 profession however with the right combination of agile kanban and scrum lawyers

19:11 at lonely planet have transformed from a crushing work environment to crushing

19:14 it there are a lot of other organizations from different domains

19:18 that are using agile although agile is often praised for its flexibility

19:21 and quickness it does come with some trade-offs with planning and a dedicated

19:26 team these added challenges can be overcome as you already know

19:30 agile is framed around a time boxed approach and priorities are constantly

19:33 changing this makes it hard to nail down a set delivery date

19:36 on projects additionally additional sprints or iterations

19:40 can be added to the project strategy increasing project timelines and pushing

19:44 back previously set deadlines unlike

19:47 waterfall agile development only works well when the entire development team is

19:51 committed to the project for the duration this may be a challenge

19:54 for some teams that have a lot going on at once

19:57 and may even prove challenging for individual

19:59 developers agile teams are generally small

20:02 so all team members must be knowledgeable about a variety of processes

20:05 along with the agile methodology itself in agile because the initial plan

20:10 might not be set the actual final product can vary greatly

20:13 from what was proposed agile is very flexible throughout the entire project

20:17 so iterations can be added customer feedback can alter plans and timelines

20:21 can change resulting in a potentially new deliverable most often than not

20:26 an agile team's documentation tends to get sidetracked which makes it harder

20:29 for new members to get up to speed that's another drawback that we

20:33 have here let's go a little deeper and try to understand

20:36 the people processes and tools behind

20:38 the success of agile methodology let's begin

20:41 with components of agile methodology because if we directly jump into the life

20:45 cycle you will come across terms that you might not be

20:48 familiar with the first component that we have is sprints or at times

20:52 referred to as iterations as well an iteration is a fixed

20:55 time period during which the development takes place this means everything

20:59 happens during an iteration analysis design

21:02 coding testing typical iterations last one

21:05 to two weeks however some may go as long as four weeks

21:08 and at the end of every iteration a working piece of software is

21:11 delivered as you move forward the idea is to continuously repeat

21:15 these iterations until your product is feature ready user stories a user story

21:20 is a tool that captures an informal and general explanation of a software

21:24 feature written from the perspective of the end user it basically

21:27 is an informal description of user requirements spoken in plain english a user

21:32 story basically involves three things a persona an action and a benefit

21:37 here are some examples of a possible user story as a marketing

21:41 data analyst i need to run the salesforce and google analytics report

21:45 so that i can build the monthly media campaign plans

21:48 as a credit card holder i want to view my statement balance so

21:51 that i can pay the balance due as a frequent flyer i

21:54 want to rebook a pass trip so that i can save time

21:56 booking trips i take often epics an epic is very much like

22:00 a user story it is also an expression of a business requirement

22:04 but it is large and will usually have to be broken down

22:06 to be able to address it be it for reasons of time

22:09 or complexity let's say we have a user story that goes

22:12 like this as a customer i want to be able to select

22:15 the payment method so that i can choose the most convenient one

22:18 then an epic related to this user story would be as a customer

22:22 i want to be able to purchase products online surely this will

22:25 have to be broken down into quite a number of user stories

22:28 right features in agile development a feature is a chunk of functionality

22:32 that delivers business value features can

22:35 include additions or changes to existing functionality

22:38 the features for a sprint become more detailed with input from customers

22:41 testers and developers working together no feature is described in detail until

22:46 it's prioritized for a sprint for example i want to build

22:50 a site that sells shoes my features might be display informative home screen

22:54 user registration user login display products and others that you can see

22:58 on the screen product backlog obviously when you are working on a project

23:03 you have a list of user requirements new features bug fixes

23:06 infrastructure changes and such all these items are listed in an artifact

23:10 and that artifact is referred to as backlog the product backlog is

23:14 the single authoritative source for things that a team works on stand-up

23:19 meetings stand-ups are one of the fundamental parts of agile development

23:23 in many sports like football and rugby the team huddles before each play

23:27 it keeps the team informed connected and calibrated throughout the game

23:31 for software teams the stand-up is

23:33 like the team's huddle daily stand-up meetings

23:36 also known as daily scrum meetings are a great way to ensure

23:39 everyone is on track and informed to reduce the complexity the meeting

23:43 takes place at the same time in the same place daily

23:46 this meeting is normally time boxed to a maximum duration of 15 minutes

23:50 though this may need adjusting for larger teams agile board an agile

23:54 board is a visual representation of the progress of a software project

23:58 it helps you and your team to track the progress of your project

24:00 and ensures transparency the board is divided into three columns labeled

24:04 to do and progress and done you can place sticky notes or index

24:08 cards one for each task the team is working on in each

24:11 column these columns reflect the current status of the tasks the format

24:16 of the tables is not fixed as such i mean different

24:19 agile methodologies have different kinds of boards well these are the key

24:23 terms that you will come when dealing with agile methodology now let's

24:27 learn about the people that are part of the agile team

24:29 when we talk about agile teams

24:31 we mean well-functioning and high-performing teams

24:33 that are able to innovate solve complex problems and deliver at a high

24:36 pace the well-functioning agile team is at the core of an agile

24:40 organization so who exactly is a part of this agile team

24:44 let's figure that out so product owner often an executive or key

24:48 stakeholder the product owner has a vision for the end product

24:52 and a sense of how it will fit into the company's long-term goals

24:55 a product owner is also responsible for defining the goals of each

24:58 sprint managing and prioritizing the team backlog and for making decisions

25:02 in a timely manner finally the product owner ensures that product development

25:07 translates into value for the stakeholders

25:10 communication with end users business executives partners

25:13 and the development team is therefore a key responsibility next we have

25:18 scrum master or a team lead this role is referred to as scrum

25:21 master in scrum framework or team coach or project lead in other

25:25 methods he or she is responsible for facilitating the team obtaining resources

25:30 for it and protecting them from any sort of impediments and obstacles

25:33 in simple terms they act as a coach and an advocate

25:36 for the entire agile team team leads also encompass the soft skills

25:40 of project management but not the technical

25:42 ones such as planning and scheduling activities

25:44 that are better left to the team as a whole then we

25:47 have team members team members are the ones who execute the work

25:51 in each sprint they have varied roles and skills but all are

25:54 responsible for getting stuff done on time and an excellent quality team

25:58 members accept assignments work on them

26:00 independently and collaboratively consult each other

26:02 and the scrum master when they have questions and have to ward

26:05 off distractions for the duration of the sprint the key responsibilities

26:09 of the development team is to perform work sprints as per the requirements

26:12 provided by the product owner and coordinated by the scrum master

26:16 then there are stakeholders the stakeholder

26:18 position may not be directly involved

26:20 in the product development process but is used to represent a range

26:23 of key roles that impact the decisions and work of the team

26:27 the key roles here can be business executives production support staff investors

26:32 external auditors program or portfolio managers

26:35 or maintenance professionals who are part

26:36 of the project the stakeholders should be kept up to date

26:40 on the product and sprint goals also the input from stakeholders is key

26:44 to direct the progress of the project in different directions to align

26:47 product development with business goals apart from these typical roles large

26:51 enterprises working on large projects may include more roles into the agile

26:55 teams which include technical and domain

26:58 experts with the knowledge of technology

27:00 as well as a wide variety of stakeholder requirements or expectations

27:04 an independent testing and audit team

27:06 working in parallel that validates their work

27:08 throughout the life cycle also at times an architect owner may be

27:12 required for architectural envisioning planning and decision

27:15 making i would like to reiterate

27:16 that these roles may change from framework to framework and new roles

27:20 might get added to agile teams based on the requirement however there

27:24 are a few universal characteristics that most agile team structures should have

27:28 agile teams should have a clear purpose it leads to focus which

27:32 increases the speed and value delivered by the teams by 100 t-shaped

27:37 skills the t-shaped metaphor comes from the idea that an individual can

27:40 possess deep skills in one or more specific areas as well

27:44 as a broader range of shallower skills and areas of expertise other than one's

27:48 own cross-functional agile team members have

27:50 skills outside their traditional areas team

27:53 size really matters teams of five to seven people who are high-performing

27:57 are 100 faster entrepreneurial an agile team member is one that doesn't

28:02 wait to be told what to do they do their job well

28:05 because they want to not because they are forced to do so

28:08 team-oriented team players prioritize the success of the team over their own

28:12 personal glory if everyone is delivering on time and sinking well together

28:16 they see that as a win committed to excellence one of the key

28:20 benefits of agile projects is delivering quality work faster team members who

28:24 are committed to excellence don't settle for average they're not hung up

28:28 on perfection but they're dedicated to always producing their best work so

28:32 these are a few typical characteristics that agile teams have by now

28:36 i am sure you understand how traditional teams differ from agile

28:39 teams let me summarize traditional teams follow a top-down approach it means

28:44 that the project manager is responsible for getting the job done when

28:48 a problem occurs it escalates to managers however agile teams are self-organized

28:54 and self-managed when problems occur the entire team works together

28:58 as a unit to resolve the issue traditionally a project is organized around

29:02 component teams so if a particular release requires a range of different

29:07 expertise it will need to involve multiple component teams different teams will

29:11 have different sets of priorities which

29:13 inevitably leads to bottlenecks in the product release cycle whereas agile teams

29:18 are cross-functional and interdisciplinary it means

29:20 that a group of people with different functional expertise are working toward

29:24 a common goal in a traditional

29:26 team an organization evaluates individual performance

29:29 in an agile team an organization evaluates team performance in the traditional

29:34 approach you have distinct roles and job titles but in agile teams

29:38 are usually cross-functional in here skills

29:40 matter more than titles lastly traditional

29:43 teams are not a fixed size whereas the agile teams are usually short

29:47 like around three to nine people per team so everyone that's about

29:51 agile components and teams now let us learn the phases of the agile

29:55 process or life cycle at its core agile is a continuous cyclical

29:59 process that encourages flexibility experimentation

30:02 and adaptability the six phases of agile

30:05 are flexible evolving and often overlap the first phase is requirement analysis

30:11 during this phase of agile methodology

30:13 projects are envisioned crafted and prioritized

30:16 based on the needs of the customer and the goals of the company

30:19 for every concept the team defines the business opportunity and determines

30:22 the time and work it'll take to complete the project the next

30:26 phase is planning in this step teams are formed and appropriate

30:30 funding is designated the teams work

30:32 with stakeholders to determine the requirements

30:34 and formulate them it is in this step the team uses user

30:38 flow diagrams or high-level uml diagrams to demonstrate how the new

30:42 feature should function and how it will fit into their existing system

30:45 the next phase is the design phase once a team has defined

30:49 requirements for the initial sprint based

30:51 on stakeholder feedback and requirements the work

30:53 begins designers developers and other team members begin working on their first

30:58 iteration of the project with the goal of having a working product

31:01 to launch at the end of the sprint after design comes implementation

31:05 quality assurance testing documentation development internal

31:08 and external training and final release

31:10 of the iteration goes into production during this phase of the process

31:14 you're nearly ready to release your product into the world testing

31:18 in this step teams continue to create troubleshoot and support the software

31:22 product as it progresses by the time

31:24 development reaches the testing and deployment

31:26 phases the client has already seen the project multiple times release

31:30 and evaluation in this step the product is delivered to customers for them

31:34 to use customer notifications and migrations

31:37 are considered along with end-of-life activities

31:40 afterward the agile software development lifecycle

31:43 phases start anew either with a new

31:45 iteration or by moving toward the next stage in the further

31:48 iterations you update the already installed

31:51 software introduce new features and resolve

31:53 bugs that's how the life cycle of a typical agile methodology looks

31:57 like like i mentioned earlier more often than not the phases evolve

32:01 as the product changes or overlap one another so there are multiple

32:05 stages in the process concurrently now the question is how does the team

32:10 know if they would be completing the work on time how do

32:13 they keep track of their progress estimate the amount of time they

32:16 might need to complete the sprint how do they measure success

32:20 this is where agile metrics come in without bringing agile metrics

32:24 into the picture using agile won't bring much value to a company

32:28 i am sure you might have heard the work metris before they are

32:31 just standards of measurement but what do you exactly measure using

32:35 metrics you can measure the development

32:36 process gauging productivity work quality predictability

32:40 and health of the team and products that are being developed however

32:44 tracking multiple metrics can become counterproductive

32:47 is important to select the key metrics

32:49 to track and incorporate within their business and you don't want

32:52 to measure too many things and scatter your team's focus so which metrics

32:56 matter and how do you choose them here are some things you

32:58 need to consider before deciding on the metrics for your project to track

33:03 firstly metrics should be used by the members of the agile team

33:06 and not outsiders they should not be imposed or measured by management

33:10 they should be used voluntarily by agile teams to learn and improve

33:14 secondly the agile metrics should serve

33:15 as conversation starters metrics should not

33:18 just be numbers they should be the starting point of a conversation

33:21 about process and roadblocks affecting the team the agile team also

33:25 needs to have a clear strategy regarding what it plans to do

33:28 with the numbers collected and how the metrics would impact the future

33:30 of the software project thirdly agile metrics should work together with other

33:35 metrics to provide a balanced picture did you know that even a great

33:38 metric when used alone might lead to tunnel vision and incentivize teams

33:42 to maximize the metric at the expense of all else using several

33:46 metrics together provides a balanced picture of agile activity also the metric

33:51 should be used to answer a specific question about agile processes not

33:54 just measured for the sake of measurement lastly every metric that you

33:58 use should be easy to calculate and understand metrics that are overly

34:02 complex or not fully understood will not be useful in guiding you

34:05 and your team's activities even if they provide good insights into a team's

34:09 work now with these points in mind let us look

34:12 at a few of the top metrics used by agile teams the first

34:15 metric that we have is sprint burndown we have an agile methodology

34:19 called scrum as you already know scrum teams organize development into time

34:24 box sprints at the beginning of the sprint the team forecasts how

34:28 much work they can complete during a sprint a sprint burndown report

34:31 is used for tracking the completion of different tasks during a sprint

34:35 time and work left to complete are the two main parameters

34:37 of measurement in this case next up we have velocity velocity is

34:42 the average amount of work an agile team completes during a sprint measured

34:45 in either story points or hours and is very useful for forecasting

34:50 as time passes velocity tends to evolve if the velocity declines

34:54 it's a sign that the team needs to fix something so

34:57 the number of story points completed over the past few sprints gives you

35:01 the sprint velocity velocity is powerful because it's a result metric you

35:05 will know how much value was actually delivered to customers in a series

35:08 of sprints while velocity is an important metric it cannot be used

35:12 as a measure of competence or performance of the agile team be

35:15 careful not to compare velocity across teams because each team's velocity

35:19 is unique next on the list are lead time and cycle time

35:23 they are very simple to understand both these metrics show you how

35:26 long work items spend in a given process however there is also

35:30 a clear differentiation between them lead time shows you the total time

35:34 from the moment a story enters the system in the backlog until

35:38 it is completed as part of a sprint or released to customers

35:41 lead time is an important metric

35:43 actually more important than velocity the reason

35:46 for this is it provides the exact end-to-end time calculation for every

35:49 process as shown on the screen the cycle time is a subset

35:53 of lead time it measures the time for a task to go

35:56 from started or in progress to done in other words with cycle

36:00 time you can measure how many hours or days someone actively worked

36:03 on a task to complete it it is a powerful metric because

36:06 it is a very simple metric that can raise a red flag

36:09 when items within sprints across your entire system are not moving forward

36:13 the fourth metric that we have is the cumulative flow diagram

36:16 cumulative flow is an important kanban metric for ensuring a consistent flow

36:20 of work across the team it shows the status of tasks

36:24 in a sprint a release or across software teams as you can see

36:28 in the image the stories and the various story points are plotted

36:31 in the vertical axis while the horizontal axis depicts time different colors

36:35 are used to depict the different stages the stories are in bubbles

36:39 or gaps in any one color indicate shortages and bottlenecks for example

36:43 a big bubble in the chart in a verification or testing stage

36:46 indicates this stage has insufficient resources now why is it important just

36:51 like burn down charts the power of this metric is in its

36:54 visual simplicity you can grasp a process in one glance and immediately

36:58 identify issues next we have control charts in agile control charts focus

37:04 on the time duration from the in progress to the complete status

37:06 of tasks their purpose is mainly to check the cycle time

37:10 of a single issue what do you think measuring cycle time is important it

37:14 is an efficient and flexible way to improve a team's processes

37:17 because in the case of changes you can discern the results instantly

37:20 and make any further adjustments right away lastly we have throughput

37:25 in agile throughput measures the average number of work items processed per unit

37:29 of time you can think of it as a measure for story

37:32 points per iteration it represents

37:34 a team's productivity level using throughput you

37:37 understand the effect of workflow on business performance and can get a better

37:40 overview of the capacity of your team in general throughput is one

37:44 of the most crucial agile performance metrics to measure the throughput

37:47 of your team week by week you can use the throughput run chart

37:51 actually there are many other very useful metrics that are widely used

37:55 and are worth mentioning a few of them are code coverage net

37:58 promoter score epic and release burn down work in progress escape defects

38:03 failed deployments and many others

38:05 the agile approach is often mistakenly considered

38:08 to be a single methodology yet there are dozens of methodologies

38:11 and certain practices that have not been touched upon in this tutorial since

38:16 the inception of agile a variety of methodologies have emerged the most

38:20 popular and common ones are scrum extreme programming feature driven development

38:24 adaptive software development crystal and lean

38:27 software development teams generally pick one

38:29 or two methods the most widely used methodologies are scrum and xp

38:34 which dovetail nicely also there is scrumban which is another popular hybrid

38:38 methodology let us go through a few of them in detail let

38:42 us begin with the scrum framework scrum is undoubtedly the most used

38:47 of the many frameworks of the agile methodology scrum is a lightweight

38:51 agile framework for developing delivering

38:53 and sustaining complex products it works

38:56 by breaking down large products and services into small pieces that can

38:59 be completed by a cross-functional team in a short time frame it

39:03 addresses two important issues which are delivery speed and a flexible way

39:06 of handling ever-changing client requirements when

39:09 you talk about scrum there are

39:11 three things that you should know roles artifacts and events if you

39:15 are interested to know more you can refer to the what is

39:17 scrum video on our youtube channel coming back let us quickly understand how

39:22 the scrum process works the scrum process starts with a backlog

39:26 the product owner creates a product backlog which is a list of specifications

39:30 from the client or end users using input from all the stakeholders

39:34 all the requirements are entered into the backlog as user stories after

39:38 the backlog is finalized the product owner and development team conduct sprint

39:42 planning during sprint planning the team pulls a small chunk from the top

39:46 of product backlog items to work on during the sprint that chunk

39:49 becomes the sprint backlog on a daily basis the development team

39:53 coordinates their work in a daily scrum along the way the scrum

39:57 master helps the scrum team perform at their highest level and make

40:00 smooth progress toward their spring goal at the end of each sprint

40:04 the development team delivers a functioning piece of the product to show

40:07 for their work the development team holds a sprint review to demonstrate

40:11 what they have accomplished during the sprint any stakeholders senior managers

40:15 and other affected departments such as marketing customer support and others are

40:19 invited to attend and give feedback after the sprint review the team gathers

40:23 for a sprint retrospective to discuss what went right or wrong

40:27 and areas for improvements for further sprints they make tangible plans for how

40:31 to improve their own process tools and relationships unlike in the sprint

40:36 review where the focus is on the product in sprint retrospectives the focus

40:40 is on the process as the next sprint begins the team

40:43 chooses another chunk of the product backlog and begins working again beyond

40:48 the sprint the cycle repeats until enough items in the product backlog

40:51 have been completed the budget is depleted or a deadline arrives this way

40:56 scrum ensures that the most valuable work has been completed by the time

40:59 the project ends now let us move on to the next

41:03 methodology kanban kanban is a highly visual way of executing agile its

41:08 origin dates back to the 1940s a toyota engineer named taihiono created

41:14 a system that used paper cards for signaling and tracking demand

41:17 in his factory naming the new system kanban since then the kanban development

41:22 methodology has gained quite a noticeable

41:24 popularity kanban focuses on maintaining

41:27 a continuous task flow and continuous delivery at the same time the team

41:32 is never given more work than it can handle this is accomplished

41:35 through the two primary principles of kanban visualize your work and limit

41:39 the work in progress wip here's how these principles are applied

41:44 principle one is to visualize your work first you collect the work

41:48 required for a project and document it on the cards the cards

41:51 are then placed on the kanban board the kanban board is split

41:55 into categories of work to be done work in progress and completed

41:58 work and teams can add more categories as necessary to better visualize

42:02 their process each task is recorded on a kanban card as each

42:06 card is addressed it moves to the next phase until it's moved

42:09 completely through the workflow this is how the entire team sees

42:13 the status of the work being done understanding and observing the current flow

42:17 of work will help you visualize how tasks are progressing through

42:20 the workflow the next principle is to limit work in progress the kanban

42:24 methodology puts strict limits on the amount of work in progress at any

42:28 given time you limit the workflow by limiting the number of cards

42:31 allowed in each column based on your team's capacity and the nature

42:34 of their work so once the limit is reached no more cards

42:38 can be added there like the number two on the second column

42:41 so at a point in time you cannot have more than two

42:44 cards in the second column when you limit work in progress it

42:48 helps teams to complete the work at hand before moving to the next

42:51 one it identifies bottlenecks and it encourages individual contributors to rally

42:55 together to fix them in a nutshell that's how kanban teams work

43:00 it's an ideal approach for projects with lots of incoming tasks

43:03 that vary in priority and size now let us talk about another popular

43:07 agile methodology extreme programming often used with scrum xp is an example

43:12 of how agile can heighten customer satisfaction this is a typical agile

43:16 development framework developed by kentbeck

43:19 and can be adapted to development companies

43:21 of various dimensions it involves a high degree of participation between two

43:25 important parties in the software exchange

43:27 customers and developers customers inspire further

43:30 development by emphasizing the most useful features of a given software product

43:34 through testimonials the developers in turn

43:37 bring up software upgrades on this feedback

43:39 while continuing to test new innovations every few weeks let's check

43:43 how sophie's team uses xp to develop a new app the first

43:47 phase of extreme programming's life cycle is planning where customers or users

43:51 meet with the development team to create user stories or requirements based

43:55 on the feature descriptions collected from customers in the form of user

43:58 stories sophie builds a list

44:00 of customer requirements these requirements are then

44:03 used to draft a release plan for the entire game the software

44:07 developers write the test plan for each iteration as a final planning

44:10 activity the team then starts working on designing and developing the software

44:15 the unique point here is that the team works in programmer pairs

44:18 to produce higher quality software during the iteration the team holds daily

44:23 meetings to ensure there are no roadblocks and obstacles the software is

44:27 then sent for testing again using paired programming posts that the software

44:32 is released to customers for acceptance testing the customer delivers feedback

44:36 in the form of more user stories the cycle repeats until the software

44:40 is delivered this methodology offers trust to the developers by motivating

44:44 them to accept changes in the customers requirements even if they arrive

44:48 at a later stage of the development cycle the next one that we

44:51 are exploring is crystal methodology crystal

44:54 is an agile software development approach

44:56 that mainly focuses on people and their interactions as opposed to processes

45:00 and tools it is a very very flexible framework and avoids rigid

45:04 processes because of its human-powered

45:06 or people-centric focus crystal method is based

45:09 on two fundamental assumptions teams can

45:11 streamline their processes as their work

45:13 and become a more optimized team projects are unique and dynamic

45:17 and require specific methods alistar believed that one size doesn't fit all

45:22 in other words it means that one method can't get applied to every

45:25 project that is why he designed crystal in a way that it

45:28 has various methods the crystal family includes variants such as crystal clear

45:33 crystal yellow crystal orange and crystal red now that question that arises

45:38 is how do you choose between these crystal methodologies which approach

45:41 will be most suitable for your projects depends on three dimensions team

45:44 size criticality and the priority of the project the maximum number

45:49 of people that need to be involved in a project depends

45:51 on the size of the project bigger projects more people the number

45:56 of team roles also depends on the project size there are four levels

46:00 of criticality comfort discretionary money essential

46:03 money and life like any other agile methodology crystal focus on early

46:08 delivery of working software frequency less

46:10 bureaucracy and high involvement of users the crystal family suggests that each

46:15 project is unique and requires the application

46:17 of different processes practices and policies

46:20 this is why it is perceived as one of the most

46:22 lightweight approaches to agile project management apart from these we also have

46:26 lean development and feature driven development or fdd you may be wondering

46:31 what is the best agile project management methodology xp scrum kanban crystal

46:36 or fdd well any selection that you might make should ultimately

46:40 depend on the demands and processes that factor into your business culture

46:44 with this we have covered almost

46:46 every fundamental topic related to agile methodology

46:49 let's move on to the next part of this tutorial scaling agile methodology

46:53 with the amount of benefits agile is offering by now most

46:56 business leaders are familiar with agile

46:58 innovation naturally leaders who have experienced

47:01 or heard about agile teams are asking some compelling questions what if

47:05 a company were to launch dozens hundreds or even thousands of agile teams

47:08 throughout the organization can agile be applied at scale would scaling up

47:13 agile improve corporate performance as much

47:15 as agile methods improve individual team

47:17 performance answering all these questions yes agile can be applied at scale

47:22 agile can be applied across multiple teams and projects and works for both

47:26 on-site or remote teams or a hybrid of both there's no right

47:30 way to scale agile but many organizations have had great success evolving

47:34 their processes teams and cultures using

47:36 frameworks for scaling agile let's quickly

47:39 go through top scaled agile frameworks first we have safe or scaled

47:43 agile framework it is a set of organization and workflow patterns

47:47 for implementing agile practices at an enterprise

47:49 scale it was formed around three primary bodies of knowledge agile software

47:54 development lean product development and systems

47:56 thinking safe is prescriptive and addresses the enterprise at four levels team

48:01 program value stream and portfolio

48:04 it encourages alignment collaboration and delivery

48:07 across large numbers of agile teams large-scale scrum is simply a regular

48:11 scrum applied to large-scale development it builds on top of the scrum

48:15 principles such as empiricism and cross-functional

48:18 self-managing teams and provides a framework

48:20 for applying that at scale la ss is a good starting point

48:23 when you already have scrum in place and are just beginning to scale

48:26 up with more teams one at a time the framework stresses

48:29 the idea that scaling frameworks should be minimalistic by that i mean it

48:34 should include fewer rules roles and artifacts to drive success next

48:38 up we have disciplined agile or da it's a process decision framework

48:42 that provides a comprehensive guide to everything you need for an agile

48:45 transformation d a utilizes scrum and kanban

48:48 along with transformation knowledge in areas

48:50 like hr and finance governance devops portfolio management and more it is

48:55 often considered more flexible and easier to scale than other methods what

48:59 makes da especially interesting and useful is that it is based upon

49:03 real data providing you with an insight into what's going on in other

49:06 organizations lastly we have scrum at scale scrum at scale is basically

49:11 an extension of the scrum framework it is usually adopted by organizations

49:15 that have already succeeded in implementing scrum at the team level

49:18 and are looking to spread it throughout the organization the main goal

49:22 here is to align growing organizations around one common and shared set

49:25 of goals coordination is managed through a scrum of scrums which is

49:29 a daily meeting where multiple scrum masters and chief product owners meet

49:32 to discuss their work in progress apart from the ones we discussed

49:36 there are a few others namely nexus enterprise scrum spotify lean

49:41 management agile portfolio management and others

49:44 please be informed that these frameworks

49:45 can add unnecessary processes when they're applied without thought or intent be

49:50 it scaling agile to enterprise level or implementing it in small teams

49:53 the successful agile transformation only occurs

49:56 when teams follow certain best practices

49:59 let's quickly go through a few of the agile best practices agile

50:02 advocates that entire team should function

50:04 like closely integrated units this includes

50:07 teams like project management developers quality

50:10 assurance and the customer more frequent collaboration

50:13 the agile team should attend daily meetings so as to decide

50:16 on the day's work and dependencies

50:18 this is because constant communication is considered

50:21 one of the most important factors essential to team integration one

50:24 of the most important principles relates

50:26 to regularly inspecting and adapting at the end

50:28 of each sprint this means that the team should inspect its

50:31 own practices and then decide as to what to change and how

50:34 to adapt to the change the agile methodology encourages teams to account

50:38 for any distractions that may come up during an iteration in advance

50:42 thus to avoid any end moment surprises the delivery team should try

50:45 to estimate the efforts that may go into dealing with the risks

50:48 and roadblocks and they should prepare

50:50 plans for end deliverables accordingly plan

50:53 do sprints when there are enough items in the product backlog otherwise

50:57 you risk that your project suffers from scope creep this is what

51:00 happens when the scope of your project grows without control because you

51:04 failed to fully define the scope of the upcoming sprints in the backlog

51:07 setting communication standards is important remote

51:10 communication is even harder during agile

51:12 development even if teams meet every day for daily stand-up meetings

51:16 therefore it is important to define communication guidelines and write them down

51:20 in a document that will be distributed among all team members prioritize

51:24 tasks in the product backlog one of the agile best practices that is

51:28 always recommended is that the user stories and features should always be

51:32 prioritized based on the business value being offered by them and the risks

51:35 involved well these are just a few best practices that teams

51:39 can follow to ensure success you can always look for more best

51:42 practices and see what other enterprises are applying till now we have

51:46 touched a lot of facts such as agile becoming mainstream scrum being

51:50 the most popular framework a lot of domains using agile popular agile

51:54 metrics and such well all these facts are statistically verified you will

51:59 need all the necessary information to make informed decisions in the midst

52:02 of the economic uncertainty and develop a successful career in the agile

52:05 sphere let's uncover some interesting correlations

52:08 that i picked up from the 14th

52:10 annual state of the agile report produced by collab net version

52:13 1 now part of digital.i so let's talk numbers the first

52:18 fact that i have here is that we have seen increased agile

52:21 adoption over the past few years as of may 2020 out

52:24 of 40 000 correspondents that participated in the survey 95 of them reported

52:29 that their organizations are practicing agile

52:31 development methodologies agile methodology which took

52:35 off in the software industry following the agile manifesto in 2001 and has

52:40 since then spread to all kinds of management challenges in every other

52:43 sector not just software we can now see agilent manufacturing budgeting human

52:48 resources retail petroleum auditing and agile organizational culture well it is

52:54 not much to say that the future is more agile next up

52:57 in the report accelerating software delivery and enhancing the ability to manage

53:01 changing priorities were listed as the two

53:03 main reasons for adopting agile methodology

53:06 the other improved capabilities that continue to round out the top

53:09 five are business or it alignment team morale delivery speed or time

53:13 to market and team productivity now let us check out the benefits

53:17 reported by respondents the top five benefits of adopting agile are built around

53:21 speed and adaptability the other

53:24 benefits listed were business alignment delivery

53:26 time team morale project risk reduction and others with project cost reduction

53:31 last on the list i already mentioned earlier that agile is

53:34 an umbrella term for various methodologies

53:36 scrum being the most popular one according

53:39 to the 14th annual stage of the agile report scrum remains

53:43 the most widely used agile framework with at least 75 of the survey

53:47 respondents practicing scrum or a hybrid that includes scrum next to scrum

53:51 we have kanban extreme programming lean and many others a significant shift

53:56 in agile techniques occurred as product

53:58 roadmapping increased 9 while release planning

54:01 decreased 11 the main reasons for this change may include a general

54:05 increase in continuous integration continuous deployment

54:08 and better defined program increment planning

54:11 according to the survey the top five agile techniques that help teams

54:14 adhere to the 12 principles

54:16 of agile include daily stand-ups retrospectives sprint

54:19 or aeration planning sprint or iteration review and short iterations and not

54:23 surprisingly when it comes to scaling agile safe is the scaling framework

54:27 of choice again the scaled agile framework or safe continues to be

54:31 the most popular scaling method cited by respondents increasing by five percent

54:36 over last year and outpacing the number two choice scrum at scale

54:39 by 19 lastly due to the uproaring popularity of agile methodology

54:45 there are copious amounts of tools that have jumped on the bandwagon

54:48 and have started to recognize themselves as the best agile tools honestly

54:52 there is a myriad of different tools to manage agile projects according

54:56 to the 14th annual state of the agile report jira still remains

54:59 the most popular and widely used agile tool with 67 percent of respondents

55:04 reported using it other popular agile tools include pivotal tracker version 1

55:08 plan box team forge lean kit asana axosoft tyga and so many

55:13 others so we have arrived at the best part for the rest

55:17 of the session i will show you the hope to use jira

55:20 software to manage your project you would have probably heard of jira

55:23 because it is one of the most widely used agile tools jira

55:27 products were built to assist teams of all types in managing their work

55:30 and it provides nearly every agile capability you can think of i

55:34 mean if you want a proper definition jira is a proprietary issue

55:37 tracking product developed by atlassian

55:39 that allows bug tracking and agile project

55:41 management nevertheless the software comes packed with a lot of cool features

55:45 as you mentioned on the slide let's quickly go through the tool

55:48 and check out its features shall we before that though jira is

55:52 loved by many teams around the world it isn't without its flaws

55:55 the biggest pitfall to jira is due to its steep learning curve

55:58 slowness and clutter it can be hard to get started with if

56:01 you haven't already used jira previously with that said let us quickly

56:05 go through the tool as you can see on the screen jira

56:08 tool provides assistance at every step of your development life cycle you

56:12 can create user stories and issues plan sprints and distribute tasks across

56:16 your software team next you can prioritize and discuss your team's work

56:21 in full context with complete visibility also you can ship your products

56:25 with ease based on your real-time visual data you can make important

56:29 decisions and improve team performance since all the teams might not have

56:33 the same workflow jira allows you to customize your workflow and like

56:37 i said before you can easily integrate jira with the tools you're

56:40 already using you can also create easy to follow roadmaps for your teams

56:45 and most importantly all these tasks can be automated on jira

56:48 that way you can save time and stay focused on work moreover

56:51 you can extend jira software with thousands of apps such as aha

56:55 adobe zephyr github and others as you can see jira allows you

56:59 to host your ideas and processes on cloud with multiple pricing options

57:03 that are just right for your teams we will get to the pricing

57:06 part a little bit later also thousands of modern software teams

57:09 already use jira software and other solutions from the atlassian suite

57:13 a few of its top customers airbnb spotify cisco dominos ebay rosetta stone

57:19 and many others now let us try out a few features first

57:23 of all if you go to pricing you can see that jira

57:26 is available for free though only a few features are available

57:29 in the free package based on requirements such as team size and scale

57:33 of your operation you can always go for standard premium and enterprise

57:37 plans please explore pricing in detail before opting for it i have

57:41 already signed in for a free plan it's quite easy and credit

57:44 card details are not required you can either give your email it

57:48 or log in through other means such as your google account

57:50 or microsoft account and others as you can see on the screen i

57:54 will now create a new account and show you how to get

57:56 started first you need to provide an email id for your account

58:01 and then you need to choose a unique name for your site

58:03 then click on agree once you find a suitable site name also

58:07 as i mentioned earlier you do not need to provide the credit

58:10 card information to create an account it might take a while once

58:14 you click on agree just like any software jira will ask you

58:17 a few questions for example what type of team do you work

58:21 in let's say software development and then your role product manager after

58:25 that it might take a while for your atlassian cloud site to get

58:28 started the next step is to invite your teammates initially you

58:32 can provide three email ids for this demo let me provide three

58:37 ids then click on continue then jiro will ask you a few

58:41 questions that will help you set up your account you can choose

58:44 to skip this step as well post that you need to choose

58:47 a template for your project it can be a next-gen template

58:50 or a classic template the basic difference is that next-gen projects provide

58:54 a streamlined experience are easier to use and quicker to set up than classic

58:58 projects they don't require any setup or configuration from a jira admin

59:03 so they're perfect for teams who want to work quickly and independently

59:06 on the other hand the classic

59:08 templates offer comparatively more features provide

59:10 customizations and are a little bit difficult to configure in this demo

59:15 i am choosing a classic scrum template later on you can always

59:18 change your template so once you choose a template you will be

59:22 asked to create a project give your project a unique name

59:25 and key key basically is used as a prefix of your project's issues

59:30 so make it descriptive and easy to type in this case

59:33 that would be a travel guide app and the key would be tga

59:36 then click on the create button if you wish to change

59:39 the template you can change it by clicking on the change template here

59:43 once you've created your project you will land on the active sprint

59:46 page which is currently empty as you can see on the screen

59:49 jira also offers the quick start feature i'm going to close

59:53 that for now there is a product backlog section empty backlog as you

59:57 can see on the screen the product backlog contains an ongoing list

1:00:01 of your team's potential work items for the project apart from that i

1:00:05 am sure you can see a lot of other typical agile

1:00:07 features such as roadmap backlogs brand reports and many other awesome features

1:00:12 you should know that in jira teams use issues to track individual

1:00:15 pieces of work that must be completed depending on how your team

1:00:19 uses jira these issues can be stories tasks bugs a help desk

1:00:23 ticket and others issues can also have subtasks that are assigned and tracked

1:00:27 individually to know more about these issues on the left navigation pane

1:00:32 you can find a term called project setting and under that go

1:00:35 for issue types as you can see a story is a feature

1:00:38 expressed as a user goal a bug is an error we also

1:00:42 have epics an epic is a large body of work that can

1:00:45 be broken down into a number of smaller stories or issues you

1:00:48 can say then there are tasks and subtasks now let us go

1:00:52 back to the project so the next step is to add some

1:00:55 epics user stories and tasks to our product backlog to make

1:00:59 the job easier the product owner can always create a detailed user story

1:01:03 map for this travel guide app i have created a sample user

1:01:06 story map as you can see on the screen a user map

1:01:10 should be created after a detailed discussion with other team members major

1:01:13 stakeholders and others who are part of this project i have various

1:01:17 features set for different releases in release one i have mvp features

1:01:21 that are just enough to get the first version of the product

1:01:24 out with the least amount of risk by the way mvp refers

1:01:27 to a minimum value product in this example mvp features would be

1:01:32 user profile management which includes user

1:01:34 registration login and geolocation then there

1:01:37 is a search system that has various filters based on which users

1:01:40 can search for rooms places etc then there's booking payment and review

1:01:44 and recommendations as you can see the additional features which i

1:01:48 and my team thought would make my app successful we have included

1:01:51 them for the next releases such

1:01:53 as itinerary generator weather forecasting social media

1:01:57 sharing expense tracking voice search etc in releases two and three

1:02:01 this entire process is called user story mapping based on this now let

1:02:06 us go and create some epics and stories on jira let's begin

1:02:09 with epics to create epic click the create epic option on the product

1:02:13 backlog screen in the dialog box that opens you can enter

1:02:19 the details related to epic such as name description let me name

1:02:23 the epic as user profile management actually these are the basic fields

1:02:27 that are currently visible you can easily enable other fields by clicking

1:02:31 the configure fields option and enable any of that you can see

1:02:34 here let's go with the basic settings for now try to keep

1:02:37 the epic name and summary simple then click on create similarly i

1:02:42 am going to create other epics as well now we have all

1:03:00 the epics ready review and rating payment booking browse and search

1:03:05 and user profile management as you can see our first epic does not

1:03:09 have any issues yet so the next step is to create stories

1:03:12 and tasks in order to do that you just need to click

1:03:16 on the create issue button here the issue can be a story

1:03:19 a task or a bug to create either of those you

1:03:22 can just expand this and click on open create you can also

1:03:26 change the issue type here if you want to again there are

1:03:29 a lot of fields here and you can configure which fields you

1:03:31 want to give details for so let's go ahead and create one

1:03:35 give a basic summary such as user registration if you have any

1:03:39 documents related to the story like a reference or a research document

1:03:43 or anything you can upload it here next is the user story

1:03:47 description now there's a specific format to create user stories you can

1:03:52 find a detailed explanation of what user stories are and how they

1:03:55 can be created on our youtube channel anyways let me give you

1:03:59 a basic example as a new user i want to register so

1:04:02 that i can become a registered user now let us explore more

1:04:06 fields you can make any of your teammates as a reporter based

1:04:10 on their role suppose your story depends on another story then you

1:04:13 can link it with other issues using the linked issues option

1:04:16 and select the issue in question for now i am not doing

1:04:19 that then you can assign the task to the responsible person by expanding

1:04:24 this you can see all the people related to the project after

1:04:27 that set the priority of the story in this case i have

1:04:30 set it to high next up we have a field called labels

1:04:33 labels as the name implies can be thought of as a tag

1:04:36 or keyword let us leave it blank for now next up we

1:04:40 have to choose epic you just need to select the epic under

1:04:43 which you want the user story to belong in this case it

1:04:46 will be user profile management since we have not created any sprint

1:04:50 yet let us leave it blank for now finally click on create

1:04:54 now a story is created for some reason it's not getting displayed

1:04:59 let me refresh the screen and clear the filter so yes now

1:05:03 you can see the story that we just created in a similar

1:05:06 manner i'm going to create another user story let's name it user

1:05:10 login and you can upload the related files here now the description

1:05:14 as a registered user i want to be able to log

1:05:17 in using my email and password so that i can start using

1:05:20 the app so basically it has three parts who what and why

1:05:25 the next part of the user story is acceptance criteria this part

1:05:28 actually helps the development team to ensure that they have taken all

1:05:31 possible scenarios into consideration it

1:05:34 provides a deeper and better understanding

1:05:36 of the story for example in this case i can have multiple criteria such

1:05:40 as user can only submit a form by filling all the mandatory

1:05:44 fields the email provided by the user should be a valid

1:05:48 email submission from the same ip can only be made three times

1:05:52 within 30 minutes that's one way of writing to know more i

1:05:56 suggest you explore more about user stories i am let's set

1:06:00 the priority to high you can also link the user story with epic

1:06:03 once the story is created as well great now one more user

1:06:08 story is created in the same way i have created the rest

1:06:11 of the user stories as well you can always go to any

1:06:14 of these user stories and edit their details i have actually created

1:06:18 user stories for the additional feature of the app as well such

1:06:21 as itinerary generator weather forecasting etc so now your product backlog is

1:06:26 ready as you can see only my first story is linked

1:06:29 to the epic we have to link epics to other user stories as well

1:06:34 all you have to do is just click on the epic select

1:06:40 more fields and give the epic link in this case user profile

1:06:45 management similarly i am doing it for the rest of the user

1:06:51 stories as well so it's done finally as you can see each

1:06:54 of these user stories is linked to an epic now jira also

1:06:59 provides an option to change the color of your epics let me

1:07:02 just show it to you you just need to expand this and select

1:07:06 the color of your choice then you just need to refresh

1:07:11 your page to see the changes as you can see the changes

1:07:15 are applied now i want to arrange these epics and user stories

1:07:19 according to the releases i have categorized my epics and user stories

1:07:23 into multiple releases and have kept only mvp features in the first

1:07:26 release let go ahead and create a release in order to create

1:07:30 a release you need to click the versions option on the backlog

1:07:33 page as shown on the screen let's name it to release one

1:07:37 the rest of the fields are optional but i am going to assign

1:07:40 the values now itself let's assume that with all the dependencies considered

1:07:45 my team would be able to complete the first release in 50.

1:07:48 days now my release is ready i just need to map which user

1:07:52 stories that i and my team intend to compete in this release let's do

1:07:56 that based on the user story map i have around 11 user stories

1:08:00 to be completed in this release you just need to click on the user

1:08:03 story expand show more fields and under fixed versions select the version you

1:08:07 just created that would be release one simple right do that for all

1:08:12 the other eight user stories post that you will see a tag attached

1:08:20 to the user stories just like this let me do that for all the user

1:08:24 stories so these are the features that will be going in release one

1:08:29 the next step is to create a sprint in scrum you know that prior

1:08:32 to creating a sprint the entire scrum team attends a sprint planning meeting

1:08:36 to finalize the sprint backlog so basically the entire team decides what to add

1:08:41 to include in the sprint so to create a sprint all you have

1:08:45 to do is click on create sprint then drag the user stories from your product

1:08:51 backlog to sprint backlog for now i am going to add the top

1:08:55 5 user stories to my sprint backlog when you are creating a sprint

1:09:02 the important task is to estimate how long it will take as you

1:09:05 can see the estimate for the sprint is currently zero so what exactly is

1:09:09 estimation estimation is simply measuring the effort

1:09:12 needed for implementing stories or bug

1:09:14 fixes in the product backlog you can estimate the product backlog decide on how

1:09:19 many issues to include in each sprint or just calculate roughly the time

1:09:22 it will take to complete sprint backlog items or product backlog in total

1:09:27 traditional software teams give estimates

1:09:29 in a time format days weeks months many

1:09:32 agile teams however have transitioned to story

1:09:35 points apart from estimation jira allows you

1:09:37 to perform time tracking time tracking is

1:09:40 basically the ability to measure the progress

1:09:42 of the sprint and the team at a much more granular level usually

1:09:46 it is measured in minutes hours or days let's discuss story points story

1:09:52 points are units of measure for expressing

1:09:54 an estimate of the overall effort required

1:09:56 to fully implement a product backlog item or any other piece of work

1:10:00 you need to assign story points relative to the complexity of the work

1:10:03 the effort required and risk or uncertainty often the story points are given

1:10:07 in a fibonacci like format like 1 2 3 5 8 13 20 40 100.

1:10:15 now if your story point is going beyond 20 it

1:10:17 is suggested to break that story into two in this example

1:10:21 since it is the first sprint the team might not

1:10:23 really know how many stories point to add to the sprint

1:10:26 based on previous experience let's say the team has

1:10:29 decided to assign 16 story points for the first sprint

1:10:32 by default the story points field is only available to issues

1:10:35 of type story or epic let's take the user login

1:10:38 story since login is a common functionality i'm going

1:10:44 to assign two story points next i am going to add

1:10:47 the original estimate as well it just shows how much

1:10:50 time you're expecting to complete the task or in this case

1:10:53 a story let's say 3d you can start tracking time

1:10:57 by clicking on the work log here and by mentioning

1:11:00 the hours that you can already spend on this task let's

1:11:03 give two days once we do that the original estimate will

1:11:06 get updated as you can see on the screen let

1:11:09 us check out the other available features here you can

1:11:12 change the stats of the story based on the workflow

1:11:15 then change the assignee and reporter if required we also have

1:11:19 something called labels using labels you can align issues that don't

1:11:22 come under the same epic or story or just make

1:11:25 searching for stories much easier anyone from the team can

1:11:28 add them let's add a label here something like login you

1:11:32 will know its usage later apart from that you

1:11:35 can assign versions and create subtasks as well let's do

1:11:38 that for example user login can be divided into multiple subtasks

1:11:42 such as user login page ui ux design login page development

1:11:47 and forgot password workflow for each subtask you can again

1:12:01 add a signee and reporter add versions and set the priority

1:12:04 as well further you can give a very detailed description

1:12:08 of each of these tasks i am also going to add

1:12:10 a label as well same as before which is login

1:12:20 then let's set the original estimate to one one day

1:12:24 and the work log is four hours you can see

1:12:36 that the original estimate is reflecting the changes i am also

1:12:40 going to set the version to release one let's go

1:12:59 back to the project now and assign the story points

1:13:01 for the rest of the user stories as well remember

1:13:04 this is just an example and in real projects the story

1:13:07 points are decided after discussion by the entire team

1:13:12 in this example the first sprint has a total of 16

1:13:15 story points so now we have a sprint planned you

1:14:03 just need to start the sprint by clicking on the start

1:14:05 sprint option you see on the screen give a name

1:14:08 to the sprint and set the sprint duration the general sprint

1:14:11 duration is two weeks so i'm going to use

1:14:13 that in this example you can also customize the sprint duration after

1:14:18 that set the start date and click on start

1:14:20 your sprint is now ready and has begun now if you

1:14:24 check the board you can see all the epic stories

1:14:27 and subtasks that we created earlier by default you can see

1:14:30 to do in progress and done columns but you can

1:14:33 always customize the board based on the workflow you require before

1:14:40 we look into customization let us check out how to filter

1:14:43 the issues you just need to go to issues here

1:14:46 and you can easily filter all the issues based

1:14:48 on multiple options for example based on the assignee just like

1:14:52 you see on the screen you can also filter based

1:15:08 on the status or type of the issue you can also

1:15:23 apply advanced searching here i'm going to apply label

1:15:30 as a filter if you remember we had assigned a label called

1:15:43 login for the user login story and another subtask once

1:15:46 i apply that i can see all the related issues so

1:15:50 that's one way you can make use of the label

1:16:04 feature now let us customize the scrum board for that you

1:16:24 just need to click here and go for board

1:16:26 settings from the multiple options that you see here click

1:16:29 on columns here you can easily add or remove columns

1:16:39 to add a column first you need to create the status

1:16:42 and then the column you will see a new column

1:16:57 called review after in progress similarly let us create another one

1:17:01 called testing once created you can easily move the column

1:17:30 around now if you go back to the project you

1:17:38 can see that the changes are reflected and two new

1:17:41 columns are added now you can easily determine the status

1:17:45 of your tasks by moving them to different columns as you

1:17:47 can see on the screen i am getting an error

1:17:50 let me check why it's happening great now it's working you

1:18:26 can also filter your cards here based on the assignee let

1:18:46 us now discuss the other options in the board settings

1:18:48 the column we already checked earlier next up we have

1:18:52 quick filters where you can use jira query language you

1:18:55 can also set card colors and layout next up we have

1:19:05 an estimation we have already talked about estimation and time

1:19:08 tracking earlier right so you can set different estimated statistics

1:19:12 and change the time tracking criteria so please do explore

1:19:16 this session in detail lastly let us talk about reports like we

1:19:21 discussed in the theory part of the session there are

1:19:23 different metrics that are available on jira as you can

1:19:26 see we have burn down charts burn up charts cumulative

1:19:29 flow diagrams control charts and many others for example we have

1:19:34 a burn down chart that can be used to track

1:19:36 the total work remaining and project the likelihood of achieving

1:19:38 the sprint goal as you can see on the screen we

1:19:54 also have a burn up chart though it is not commonly

1:19:57 used then there is a sprint report that helps you

1:20:03 determine if your team is over committed or if there

1:20:05 is any excessive scope creep next up we have a velocity

1:20:15 chart you cannot see any stats for this example because

1:20:18 we have initiated only one sprint however the velocity metric

1:20:22 tracks the amount of work completed from sprint to sprint you

1:20:25 will be able to see the data once you add

1:20:27 more sprints there is a cumulative flow diagram which is actually

1:20:31 a kanban metric for ensuring a consistent flow of work

1:20:33 across the team it shows the status of tasks

1:20:36 in a sprint or a release there are a version report

1:20:48 and many other different kinds of reports available the point is

1:20:59 each of these reports serves different purposes it is important

1:21:02 for you to understand which metric is right for you

1:21:04 and your team well that's it guys i have just shown

1:21:15 you one sprint for better understanding in a similar manner you

1:21:19 can manage your projects using jira software what i have

1:21:22 covered here are just the basic features that jira offers

1:21:26 please go ahead and explore the jira tool and the free

1:21:28 features it offers that's it folks with this we have

1:21:32 reached the end of the session hope you have liked

1:21:34 the session if this has spiked your interest and you want

1:21:37 to know more about agile methodology i recommend you opt

1:21:40 for agile certifications at invensis

1:21:43 learning we provide various agile certifications

1:21:46 that will pave the way for your career in agile

1:21:48 for each of these certifications we are either accredited by respective

1:21:52 governing bodies or courses are in line with their guidelines

1:21:56 post enrollment you will get lifetime access to a personalized

1:21:58 learning management system lms has all the class recordings live

1:22:02 class webinar links along with assignments and case studies to practice

1:22:07 all classes are live instructor-led delivered by trainers with rich

1:22:10 domain experience thank you guys see you in the next session