Scrum Master Full Course 2026 | Scrum Master Tutorial | Scrum Master Training | Simplilearn

0:04hey everyone welcome to the scrum full

0:06course by simply La scrum is a simple

0:09yet powerful agile framework that helps

0:11teams stay organized work efficiently

0:13and deliver projects Faster by breaking

0:16work in short Sprints teams can adapt

0:18quickly gather feedback early and

0:20improve continuously and with more

0:22companies focusing on agility the demand

0:24for scrum professionals will keep

0:26growing in 2025 and Beyond in this

0:29course you'll learn everything about

0:30scrum from its core principles to key

0:33roles like scrum Master product owner

0:35and development team we also cover scrum

0:38events such as Sprint planning daily

0:40standups Sprint reviews and

0:41retrospectives it also explore essential

0:44tools like the product backlog and

0:45Sprint backlog and certification tips

0:47for PSM and learn how to use top project

0:50management tools while preparing for

0:52scrum job interviews but before we

0:54comments just some quick info for you

0:55guys if you're interested in elevating

0:57your career and becoming a professional

0:59scrum master

1:00our best rated certified scrum Master

1:02certification training is your ticket to

1:04success we guarantee you'll pass on the

1:06first attempt as you join one of our 20

1:08plus life cohorts each month for 16

1:10hours of interactive training led by

1:12globally Renown certified scrum trainers

1:14engage in Hands-On learning through

1:15roleplay simulations and case studies

1:17and gain complimentary access to Agile

1:19and scrum courses so enroll now and

1:22start your journey to becoming a

1:23professional scrum Master you can find

1:25the course Link in the description box

1:27below so without further Ado let's get

1:29started so guys what is basically in

1:31scrum scrum is an agile framework that

1:34has revolutionized the way complex

1:36projects are managed and completed its

1:39adaptability focus on collaboration and

1:41iterative approach makes it an ideal

1:44methodology for dynamic and fast-paced

1:47environments while scrum is most

1:49commonly associated with software

1:51development its principles and practices

1:53can be applied to various Industries to

1:55enhance efficiency and product quality

1:58this comprehensive tutorial

2:00aims to provide you with a deeper

2:02understanding of scrum covering its

2:03roles artifacts event processes benefits

2:07and practical implementation by the end

2:09of this tutorial you will have a solid

2:11graphs of scrum and how to leverage its

2:14potential for your projects now let us

2:16move on to the second part with the

2:18thorough discussion on what is Scrum

2:20roles the product owner plays a very

2:23crucial role in scrum acting as a voice

2:26of the customer so this is the first

2:28scrum role that we see in scrum

2:30methodology that is a product owner this

2:33individual is basically responsible for

2:35defining and prioritizing the product

2:37backlog ensuring that the team focuses

2:40on the most valuable task the product

2:42owner Works closely with stakeholders to

2:45together the requirements set clear

2:47goals and make informed decisions about

2:49the product Direction the key

2:51responsibilities of the product owner

2:53includes defining the product vision and

2:56road map creating and managing the

2:58product backlog prioritizing ing backlog

3:00items based on value risk and urgency

3:04ensuring that a team understands the

3:05backlog items and their importance and

3:08also accepting or rejecting completed

3:10work based on predefined criteria next

3:14role we have is Scrum Master the scrum

3:17Master is a facilitator and Coach who

3:19ensures that scrum framework is followed

3:22effectively this role involves removing

3:25obstacles that hinder the team's

3:26progress promoting a culture of

3:28continuous Improvement and fostering

3:30collaboration the scrum master act as a

3:33servant leader supporting a team in

3:35achieving their goals without dictating

3:37how they should work the key

3:39responsibilities of the scrum Master

3:41includes facilitating scrum events like

3:44Sprint planning daily scrum Sprint

3:47review and Sprint retrospective then

3:50comes removing impediments that block

3:52the team's progress moving ahead we have

3:54also coaching the team on scrum

3:56practices and principle then we have a

3:59tooro discussion on protecting the team

4:00from external distractions and

4:02interruptions and finally promoting a

4:05healthy team Dynamic and addressing

4:07conflicts next one we have is the

4:09development team so guys the development

4:12team consists of professionals who work

4:14collabora to deliver a product increment

4:18this self-organizing team is cross

4:20functional meaning it possesses all the

4:22skills necessary to complete the work

4:24without relying on external sources the

4:27development team is accountable for

4:29creating high quality increments that

4:31meet the definition of done the key

4:34responsibilities of development team

4:36includes estimating planning work during

4:39Sprint planning collaborating daily to

4:41achieve the Sprint goal delivering a

4:43potentially shippable product increment

4:46by the end of the Sprint then

4:48continuously improving their processes

4:49and practices and finally maintaining

4:52transparency through regular

4:53Communications and updates now let us

4:56move on and understand about scrum

4:58artifacts the the first one that we have

5:00all over here is product backlog the

5:03product backlog is a dynamic list of all

5:05the works needed for the product it

5:08includes features enhancements bug fixes

5:11and Technical tasks the product owner is

5:13basically responsible for maintaining

5:15and prioritizing the backlog ensuring

5:18that it reflects the current needs and

5:20goals of the project the product backlog

5:22is continuously refined with items being

5:24added removed or reprioritized as

5:26necessary the product backlog serves as

5:29a single source of Truth for the team

5:31providing a clear road map of what needs

5:33to be done it is essential that backlog

5:36items are well defined with clear

5:38acceptance criteria to guide the

5:40development team and delivering the

5:41expected value then we have the Sprint

5:45backlog the Sprint backlog is a subset

5:47of the product backlog containing items

5:50selected for the current Sprint during

5:52Sprint planning the team decides which

5:55backlog items they can commit to

5:57completing within the Sprint the Sprint

5:59backlog also includes a plan for how the

6:02team will accomplish such work Sprint

6:05backlog provides a focused and

6:07actionable plan for the team outlining

6:09the tasks and goals for the Sprint it is

6:11a living document continuously updated

6:14as the team progresses and learns about

6:16the work the Sprint backlog helps the

6:18team stay organized and aligned with the

6:20Sprint goal then we have is increment

6:24increment is the sum of all the work at

6:26the end of the Sprint it represents a

6:29potential shippable product that meets

6:31the definition of done a set of criteria

6:34ensuring that work is complete and of

6:36high quality the increment includes not

6:39only the new features added during the

6:41Sprint but also any improvements or

6:43fixes made to the existing features the

6:46increment provides tangible evidence of

6:49progress allowing stakeholders to

6:50inspect and evaluate the product it

6:53serves as the basis for feedback and

6:55decision- making enabling the team to

6:57adapt and refine their approach in

6:59subsequent Sprints then we have is

7:02Sprint now let us move on and discuss

7:04about some of the scrum events the first

7:07one that we have all over here is Sprint

7:10a Sprint is a time box period typically

7:12lasting 24 weeks during which the team

7:15Works to create a product increment the

7:18fixed duration of the Sprint provides a

7:20regular rhythm for the team promoting

7:22consistent delivery and continuous

7:23Improvement each Sprint begins with a

7:26Sprint planning and ends with a Sprint

7:28review and Sprint retrospective active

7:30next one we have is Sprint planning it

7:33is a event where the team defines what

7:35will be accomplished in the upcoming

7:37Sprint the product owner presents the

7:40high priority backlog items and the team

7:42collaborates to select those they can

7:44complete within the Sprint together they

7:47set a clear Sprint goal and create a

7:49plan for achieving it during Sprint

7:51planning the team breaks down the

7:53selected backlog items into smaller

7:55tasks and estimates the effort required

7:58this detail planning ensures that

8:00everyone understands the work and how it

8:02contributes to the Sprint goal Sprint

8:04planning sets the stage for a focus and

8:07productive Sprint next one we have is

8:09the daily scrum daily scrum is a short

8:12time box meeting usually lasting for 15

8:15minutes held every day during the Sprint

8:18the purpose of the daily scrum is to

8:20synchronize the team activities discuss

8:22progress and identify any obstacles each

8:25team member shares what they did the

8:28previous day what plan to do today and

8:31any issues they are facing the daily

8:33scrum promotes transparency and

8:35accountability ensuring that everyone is

8:37aligned and aware of the team status it

8:40also provides an opportunity to quickly

8:42address and resolve impediments keeping

8:44the team on track to achieve the Sprint

8:46goal next we have all over here is

8:49called Sprint review so guys Sprint

8:51review is held at the end of the Sprint

8:54to inspect the completed work and get

8:56the feedback from stakeholders the team

8:58demonstrates the product increment

9:00highlighting what was accomplished

9:02during the Sprint stakeholders provide

9:05input and the product owner updates the

9:07product backlog based on the feedback

9:09the Sprint review Fosters collaboration

9:11and transparency allowing stakeholders

9:14to see the products progress and

9:15influence its direction it also provides

9:18an opportunity to celebrate success and

9:20identify areas for improvement and

9:23finally we have the Sprint retrospective

9:26the Sprint retrospective is the final

9:28event of the Sprint where the team

9:29reflects on their processes and

9:31practices the goal is to identify what

9:33went well what could be improved and how

9:36to enhance their performance in future

9:38Sprints the team discusses these

9:40insights creates action items to address

9:42any issues the Sprint retrospectives

9:44promotes a culture for continuous

9:46Improvement encouraging the team to

9:48learn from their experiences and make

9:50incremental changes by regularly

9:52reflecting and adapting the team can

9:54optimize their processes and Achieve

9:56better outcomes now let us understand

9:59this scrum process flow the scrum

10:01process revolves around the Sprint cycle

10:04beginning with the Sprint planning and

10:06ending with the Sprint

10:07retrospective this cycle ensures a

10:09regular keyence of work and continuous

10:12delivery of value if we talk about the

10:14first one we have the Sprint planning

10:16here here the team selects the item for

10:18the product backlog and defines the

10:20Sprint goal they break down the work

10:22into smaller task and create the plan

10:24for the Sprint now guys let us discuss

10:27about the scrum process blow the first

10:30one that we have all over here that is

10:32called as Sprint planning here the team

10:35selects the items from the product

10:37backlog defines the Sprint goal to break

10:40down the work into smaller tasks and

10:42create a plan for the Sprint next one we

10:44have the daily scrum daily scrum here

10:47the team meets daily to discuss progress

10:49plans and challenges this meeting keeps

10:52everyone aligned and allows for quick

10:55adjustments third is Sprint review at

10:58the end of the Sprint the team

10:59demonstrates the completed work to the

11:01stakeholders and gathers feedback the

11:03product owner updates the product

11:05backlog based on their feedback and

11:07fourth one we have all over here is

11:09Sprint retrospective here the team

11:11reflects on their processes and

11:13practices identifying areas for

11:15improvement they create action items to

11:17enhance their performance in future

11:19Sprints I hope so you would have got a

11:22brief idea regarding scrum process flow

11:24now let us move on to understanding the

11:26benefits of scrum so guys scrum offers

11:30several significant benefits that can

11:32transform how teams work and deliver

11:35value here are some of the key

11:37advantages the first one that we have

11:39all over here is increased transparency

11:42scrum promotes transparency through its

11:44regular events and clear artifacts a

11:47daily scrum Sprint review Sprint

11:49retrospective ensures that everyone is

11:51aware of the team's progress challenges

11:54and successes this transparency helps

11:56build trust among the team member and

11:58stakeholder ERS fostering a

12:00collaborative and open working

12:02environment next one we have all over

12:04here is improved team collaboration the

12:06collaborative nature of the scrum

12:07encourages team members to work closely

12:09together leveraging their diverse skills

12:12and expertise the scrum Master

12:14facilitates this collaboration helping

12:16the team communicate effectively and

12:18resolve

12:19conflicts this teamw work leads to

12:21better problem solving Innovation and

12:23overall

12:24productivity next one we have enhanced

12:27ability to adapt to changes scrums

12:30iterative approach allows teams to

12:31quickly adapt to changes in requirements

12:34market conditions or customer feedback

12:37by delivering small functional

12:38increments regularly the team can get

12:40the feedback and make necessary

12:42adjustments this flexibility ensures

12:44that product remains aligned with the

12:46stakeholders needs and

12:48expectations and finally it provides

12:51faster delivery of valuable products

12:53increments scrums time box Sprints Drive

12:56the regular delivery of product

12:57increments enabling f time to Market

13:00this rapid delivery cycle allows

13:02stakeholders to see tangible progress

13:04and realize value sooner it also reduces

13:07the risk of project delays and enhances

13:09the team ability to meet deadlines now

13:12let us discuss some of the common

13:14challenges of following scrum

13:16methodology we all know that scrum

13:18offers many benefits but it also comes

13:20on with its own set of challenges here

13:23are some of the common issues teams May

13:25face the first one that we have all over

13:28here is

13:29resistance to change introducing scrum

13:32can be met with resistance especially in

13:35organization accustomed to traditional

13:36project management methods to overcome

13:39this resistance it's important to

13:41provide Education and Training on scrum

13:43principles and practices involving team

13:45members and stakeholders in transition

13:48progress and highlighting the benefits

13:50of the scrum can also help build support

13:53next we have handling distributed teams

13:56distributed teams can face communication

13:58and collabor operation challenges to

14:00address these issues it's crucial to

14:02leverage technology tools such as video

14:04conferencing instant messaging and

14:07collaborative software establishing

14:09clear communication protocols and

14:11regular virtual meetings can also help

14:13maintain alignment and cohesion among

14:15team members then we have managing large

14:18projects with scrum a scaling scrum for

14:21large projects can be complex one

14:23approach is to adopt Frameworks like

14:25scrums of scrums Nexus or safe which is

14:28scaled agile framework it provides

14:30guidelines for coordinating multiple

14:32scrum teams ensuring that teams are

14:35cross functional and self-organizing

14:37with clear communication channels which

14:39are very very essential for managing

14:41large projects

14:43effectively now let us dive into most

14:45interesting part that is what are the

14:48tools and softwares which are used for

14:50scrub so guys several tools and

14:52softwares can support scrum practices

14:55enhancing productivity and collaboration

14:58here are some of the most most popular

14:59options the first one I would recommend

15:02is jira jira is widely used project

15:04management tool that offers robus

15:07support for scrub it provides features

15:09for creating and managing product

15:11backlogs Sprint backlogs and tracking

15:13progress through Visual boards jira's

15:16customizable workflows and Reporting

15:18capabilities make it a powerful tool for

15:20scrum team next one we have all over

15:23here is Trello Trello is a flexible

15:26userfriendly tool that uses boards Le

15:29and cards to organize tasks it's well

15:32suited for scrum teams allowing them to

15:34create and manage backlogs plan Sprints

15:36and track progress Trello Simplicity and

15:39visual nature make it easy to use

15:42especially for smaller teams or project

15:44and finally we have Azure devops Azure

15:47devops is a comprehensive suit of

15:49development tools that supports scrum

15:51and other agile methodologies it

15:53includes features or backlog management

15:56Sprint planning continuous integration

15:58and deployment aure devops integrates

16:00seamlessly with other Microsoft tools

16:02making it a good choice for teams using

16:04Microsoft ecosystem so guys in this

16:07tutorial we have covered the fundamental

16:09aspects of scrum including its roles

16:11artifacts events and processes so what

16:14is safe scrum Master certification safe

16:17scrum Master certification is a badge

16:19that shows you know your stuff when it

16:22comes to scrum lean and agile ways of

16:24working it's like a stamp of approval

16:27that says you are great at managing aile

16:30projects especially in big companies to

16:32get this certification you have got to

16:34prove your really understand safe

16:36principles and how to use them in real

16:38situations there's an exam you have to

16:41pass called the safe SSM exam it tests

16:45what you know about the safes framework

16:47and how you would handle different

16:49challenges now let's break it down scrum

16:52is a way of working where teams tackle

16:54big projects in small and manageable

16:56steps lean is all about being efficient

16:59and cutting out waste an agile is a

17:02mindset that focuses on being flexible

17:04and responding quickly to change safe

17:07combines all these ideas and adds a

17:09layer for working in big organizations

17:12imagine you're in charge of a project at

17:14a big company you need to make sure

17:16everyone on the team knows what you are

17:18doing and those things are running

17:21smoothly that's where being a safe scrum

17:23Master comes in handy you will know how

17:26to use scrum to break down the projects

17:28into smaller task you will also use lean

17:31principles to keep things moving quickly

17:33and efficiently and you will have that

17:35agile mindset to adapt to any changes

17:38that comes your way so getting certified

17:40as a safe scrum Master is like saying

17:43hey I know my stuff when it comes to

17:45managing agile projects in big companies

17:48it's a way to show employees that you

17:50have got the skills they need to keep

17:52their projects on track and the teams

17:54working smoothly so this was about safe

17:56scum Master certification now let's

17:58understand about about the exam pattern

18:00so understanding about the exam pattern

18:03the safe scum Master certification exams

18:05follow the specific pattern designed to

18:06access your understanding here's what

18:08you need to know about the exam so the

18:10duration is 90 minutes to complete the

18:13exam then number of questions so there

18:15will be a total 45 questions and to pass

18:17the exam you will need to score at least

18:2033 out of 45 questions correctly which

18:22amounts to 73% now talking about the

18:25competency level the exam is geared

18:27towards individuals at an intermediate

18:29competency level this means you should

18:31be proficient and capable of Performing

18:33task with some assistance now the

18:35question format questions for the exam

18:37will be either multiple choice question

18:39where you have to choose one answer or

18:41multiple select format where you can

18:43choose two or three answers now talking

18:46about the delivery the exam is conducted

18:48online via web based platform it's a

18:51closed book exam meaning you can't refer

18:53to any materials during the test it'll

18:55also not allowed any outside assistance

18:58and remember remember it's timed so

19:00manage your time wisely now coming to

19:02the main part that is the cost of the

19:04exam so the cost of the first attempt is

19:06included in the course registration fee

19:07if you take the exam within 30 days of

19:09completion the course and however if you

19:12need to retake the exam or if you

19:15attempt it after the 30-day window

19:17there's a fee for $50 per attempt so

19:19it's like that all right so this was

19:21about the exam pattern now coming to the

19:24career opportunities after certification

19:26so after completing the safe certified

19:28scrum master certification you can

19:29Target a variety of job positions that

19:32leverage your knowledge of agile and

19:34scrum practices some of them are scrum

19:36Master agile coach product owner project

19:38manager program manager and iteration

19:40manager so these are the some of the

19:43positions you can opt after doing this

19:45certification all right now let's

19:47understand how to become a safe

19:49certified scrum master so let's divide

19:52the procedure or plan into Three Steps

19:54step one is create a proper study plan

19:57so let's understand that first so

19:59preparing for the safe certified scrum

20:01Master exam starts with creating a study

20:03plan this plan outlines what you need to

20:06focus on first identify the main goals

20:08and important ideas for the exam

20:10understand the key concept thoroughly

20:12this helps you prioritize your study

20:14time and ensures you cover all the

20:16necessary topics to succeed in the exam

20:19so this was about the study plan now

20:21coming to the next step which is prepare

20:23for safe certified scrum Master exam so

20:26basically the training part for

20:27preparation purposes consider enrolling

20:30in a safe scrum Master certification

20:32course over 16 hours of live instructor

20:34Le sessions you will delve into the

20:36industries of scaled agile framework

20:38mastering Agile development at a scale

20:41iteration planning and fostering High

20:42performing teams with a one-year

20:44membership to the safe Community

20:46platform access invaluable resources to

20:49support your journey professionals who

20:51pass the safe scrum Master certification

20:53exam from Simply learn will receive safe

20:56scrum master master certificate safe

20:58scrum Master digital badge for online

21:00profiles and much more you will get the

21:02link to the safe scrum Master

21:04certification course by simply learn in

21:06the comment section below all right now

21:09let's talk about the study material

21:10thing so supplement your learning with

21:12the official course materials including

21:14the safe certified scrum Master guide

21:16and additional resources provided by

21:18your choosen training provider as I've

21:20mentioned you can go through the safe

21:21scrum Master certification by simply

21:23learn and you'll get all the resources

21:25in that particular training course all

21:28right now coming to the next thing that

21:30is the third step which is mock test so

21:33mock test taking mock test is an

21:35important part of preparing for the safe

21:37certified scrum Master exam these

21:39practice tests may make the real exam

21:40helping you get familiar with the format

21:42and types of questions by giving mock

21:44tests you can access your Readiness and

21:47identify areas where you need more

21:49practice it's a great way to build

21:51confidence and improve your chances of

21:53success on the actual exam after that

21:55you can go for test analysis analyzing

21:58Mo test is crucial for safe certified

22:00Master exam preparation after taking a

22:02mock test review your answer to

22:04understand where you went right and

22:05where you made the mistakes identifying

22:08the patterns in your errors and focus on

22:10improving those areas this should be

22:12your goal so this analysis helps you

22:15fine-tune your study plan and

22:16strengthens your weak points increasing

22:19your chances of Performing well on the

22:20actual exam and the last step would be

22:22to go for the exam so by following these

22:25steps and maintaining consistency in

22:27your preparation you can confidently

22:29pursue your goal to become a certified

22:31safe scrum Master with a solid study

22:33plan regular mock test and through

22:35analysis you will be equipped to a the

22:38exam and Excel in your agile career

22:40Journey let us now start by

22:42understanding what product Vision

22:44actually means if you look up online you

22:46might find complicated explanations like

22:49it's the emotional future idea of a

22:51company but let me make it easier for

22:53you your product vision is basically

22:56your big goal what you want to achieve

22:59with your product or the impact you want

23:01to make for example Elon Musk vision for

23:04Tesla is to become the top car company

23:07for the 21st century that's their

23:09product Vision their destination some

23:12people mix up Vision with why of a

23:14product but they're not the same your

23:17vision is where you're headed while the

23:20why is the reason behind aiming for the

23:22future in business we call this reason

23:25the mission so if your vision is where

23:27you're going the mission is why you're

23:29going there having a Clear Vision is

23:31very important in product development

23:33for two reasons firstly it motivates

23:36your team and stakeholders by giving

23:38them an exciting goal to aim for and it

23:41helps you to make smart decisions about

23:44what to build and what not to build with

23:47a Clear Vision you can steer your

23:48product in the right direction and make

23:51sure everyone is on the same page we

23:53will now understand what is product road

23:56map a product road map basically out

23:58Lins your objectives guiding you towards

24:00achieving your goals for a product it's

24:02a strategic plan that details the

24:05necessary steps and timelines needed for

24:07accomplishing task product road maps

24:09play a very crucial role as they assist

24:12in prioritizing and planning ahead at

24:14each stage of product development they

24:17connect the overarching product strategy

24:20with the specific task and activities

24:23carried out by the team for example

24:25let's say you're creating a new mobile

24:27app your product road map would outline

24:29all the key features you want to include

24:31like user login messaging and photo

24:33sharing it will also break down when

24:36each feature needs to be developed

24:38tested and released to users here the

24:40product road map help us to stay on

24:42track and reach our destination

24:44launching a successful app let's discuss

24:46the key features and functions of a

24:48product road map firstly the road map

24:50serves as a high level plan charting the

24:53course from concept to final release it

24:55lays out the key Milestones deliverables

24:58and timelines the team needs to hit

25:00which are shared with stakeholders and

25:03developers to ensure everyone

25:05understands the plan and stays on the

25:06track regularly updating and Consulting

25:09the road map keeps the team focused on

25:11the big picture and the ultimate goal a

25:14vital function of the road map is to

25:15prioritize product initiatives and

25:18features by defining what will be built

25:20and when the road map enables the team

25:23to focus their efforts on the most

25:25impactful and strategic elements

25:27allocating resources efficiently the

25:30road map also communicates the product

25:32strategy to stakeholders from Executives

25:34to the sales team this visual

25:36representation Fosters buyin and

25:38collaboration across the organization

25:41road maps play a key role in managing

25:43expectations by outlining planned

25:45releases and feature rollouts and

25:47settling clear expectation for customers

25:50lastly the best road maps incorporate

25:52flexibility adapting to changing market

25:54conditions customer feedback and new

25:56strategic priorities aligned with

25:58evolving business needs we will now

26:00explore different types of product road

26:02maps and how they help us to achieve our

26:04product goals at first we have portfolio

26:07road map this road map provides a broad

26:10overview of stages for multiple products

26:13imagine you're overseeing a company that

26:15develops both mobile apps and platforms

26:17here the portfolio road map will help

26:19you to see the big picture what's

26:21happening across your product portfolio

26:23second we have strategy road map which

26:26emphasizes high level initiative and

26:28efforts to meet product goals for

26:30example it might include goals like

26:32improving user experience expanding

26:35product offerings or enhancing customer

26:37support third we have release road map

26:39which breaks down the task and timeline

26:41to finalize a product's creation this

26:44could include steps like designing user

26:46interfaces coding functionalities

26:49testing for bugs and finally releasing

26:51updates to App Stores features road map

26:54this road map basically shows features

26:56and timelines of when product features

26:58will be released it helps ensure the

27:01development efforts are aligned with the

27:03planned feature releases next we have

27:05Sprint road map it is used when the

27:07agile framework to PL the team efforts

27:10during a Sprint for instance if your

27:12team is working in a two week Sprint to

27:14add new features to a website this

27:16Sprint road map would outline who is

27:19responsible for which task during that

27:22time free next we will now understand

27:24how to create a product road map

27:26creating a effective product Road map

27:28doesn't have to be complicated with a

27:30well-crafted road map you can bring

27:32Clarity and focus to your product

27:35development Journey remember to Define

27:37your purpose identify your audience and

27:39be ready to adapt along the way let me

27:41walk you through the seven key steps the

27:44first step is to Define your product

27:46purpose what are the main goals and

27:48objectives you're trying to achieve with

27:50this product get really clear on the

27:52core purpose this will serve as the

27:54foundation of your road map next

27:56identify your audience who will be using

27:59the product and referencing the road map

28:01understanding your key stakeholders from

28:03Executives to customers will help you

28:05tailor the road map to meet the specific

28:07needs and expectation third gather input

28:10and feedback from the stakeholders talk

28:13to your customers your sales team and

28:15your developers get their insights on

28:17what's the most important to include in

28:19the road map this collaborative approach

28:22will result in more well-rounded plan

28:24the fourth step is to determine the main

28:26theme or pillars of your product road

28:28map these are the high level categories

28:30of focus areas that will guide your

28:32development efforts things like new

28:35features product enhancements or

28:37infrastructure improvements once you

28:39have those key themes identified you can

28:41break them down into more specific

28:43actionable items these are the

28:46individual task milestones and

28:47deliverables that will bring each theme

28:49to life over time with your theme and

28:52action being defined you can then choose

28:54the right format for your road map will

28:57it be a visual timeline or table of

28:59initiatives the format should make it

29:01easy for your audience to quickly

29:03understand the plan finally remember

29:05that your road map is not set in stone

29:08review it regularly and update it as

29:10needed to reflect changes in your

29:12business Market or customer needs

29:14flexibility is key to ensuring your road

29:16map remains relevant and valuable follow

29:19these seven steps and you'll be well on

29:21your way to creating a product road map

29:23that aligns your team excites your

29:25stakeholders and ultimately drives a

29:27products success we will now discuss the

29:30five free tools for creating a product

29:32road map you must now be wondering how

29:34to create effective product road map

29:36well I'm now going to share you the top

29:39five free tools that you can use to

29:41build your road map and keep your

29:42product development on track first up we

29:45have Trello Trello is a versatile

29:47project management tool that also

29:49happens to have some great road map

29:51templates that you can use next we have

29:54notion a collaborative workspace that

29:57includes road map templates in their

29:59free plan next we have got jira which is

30:01a popular tool that can be leveraged for

30:04creating and managing effective product

30:06road maps of course we can't forget the

30:08classic Microsoft Excel and PowerPoint

30:11this tried and true spreadsheet tool may

30:13not have all the bells and whistles but

30:16it's a very simple and effective way to

30:18map out your product road map we will

30:20now discuss how to make a product road

30:22map in Excel today I'm going to walk you

30:24through step-by-step process to build

30:26one using Microsoft Excel let me

30:28illustrate with an example step one the

30:31first thing you'll do is to map out your

30:33overall strategy identify the key

30:35components you need to include in your

30:36road map these could be things like

30:38product phases future releases or team

30:41responsibilities get these main elements

30:43listed out in the column this will be on

30:46the vertical axis of your road map step

30:48two you'll want to set up a timeline

30:50across the top of your spreadsheet the

30:53horizontal axis will serve as a Time

30:55reference for your road map you can

30:58break this down by in months quarters or

31:00any other time increments that make

31:02sense for your project step number three

31:04now it's time to start building out the

31:06visual elements of your road map create

31:09swim Lanes to group related task and

31:11initiatives you can even add sub swim

31:14Lanes to break things down even further

31:16this helps organize a road map and make

31:19it easier to digest at a glance in our

31:22road map example we have listed a few

31:25project steps breaking down the

31:26implementation step into two phases that

31:29is phase one phase two and also phase

31:30three step number four within each swim

31:33Lane we'll start at some shapes to

31:35represent the different components of

31:36your product road map go to insert

31:39shapes and then select the shape you

31:40would like to insert step number five

31:43draw the shape by placing the cursor on

31:46the needed position and drag it to draw

31:49adjust the width of these shapes to

31:50align with your timeline and Visually

31:53communicate the timing to each

31:54initiative of Milestone step number six

31:57move multiple shapes at once to do so

32:00click on the desired items after

32:02pressing and holding the control key and

32:04drag and drop them into the new position

32:06next we have format shapes right click

32:09on any shape and then open the right

32:11side format shape menu step number seven

32:14do not forget to add clear descriptions

32:16to your shape double click on any of the

32:18shape and start typing to provide the

32:20details of the element you want to

32:22represent you can even style the text to

32:25make it pop next we have in this step we

32:28will incorporate the key Milestones into

32:30your road map add these as a distinct

32:32shapes and group them with text boxes so

32:34you can easily move them around as

32:36needed and there you have it a

32:38comprehensive product road map built

32:41entirely in Excel the beauty of this

32:43approach is the flexibility it provides

32:45you can easily update rearrange and

32:47refine your road map as your product

32:50evolves give it a try and let me know if

32:53you have any other questions then

32:55there's something called scrum board

32:56which is used during the this flow of

32:58scrum right from product backlog to the

33:01creation of that increment so let us

33:03look at what is a scrum board which is

33:05used during the scrum practice so scrum

33:08board is a physical or virtual tool that

33:11helps team to visualize items in the

33:13Sprint back clock so it helps in

33:15tracking what is being delivered what is

33:17in progress and what needs to be

33:19delivered further so it shows all action

33:22items during the daily scrum helping

33:24keeping the team focused on tasks that

33:26need to be completion and the priorities

33:29of those the scrum board is usually

33:32present in a place that's accessible to

33:34all team members it is a visual board

33:35right and can be physical whiteboard and

33:38stickers or virtual software tools which

33:41can be used and displayed on the screen

33:44so the scrum board is divided into

33:46different slots like to-do in progress

33:49and done so when new Sprints are started

33:52the existing board is reset and new

33:54scrum board is created so since it is

33:57visual system I think it is taking the

33:59thought from KB so visual system always

34:02works effective because the moment I

34:04know I see something is uh put against

34:08my name that I need to complete this

34:10it's quite obvious to me that I will put

34:12efforts to complete it so it's a

34:14conscious effort what I will put it

34:16works on my Consciousness so something

34:19which is not visible to me it is that

34:21out of sight is out of mind so I will

34:23not work on it so I may there is a

34:25tendency to forget

34:29first slide here has to do with user

34:32stories and epics and what I want to do

34:36team is I want to before we get into the

34:40user stories I want to go to the

34:42Whiteboard and I want to just give you a

34:44little bit more

34:47information that might help us in

34:50organizing our discussion that we're

34:52about to embark on

34:54here so a word that is not

34:58in our slides is themes themes are

35:03epics and user stories grouped together

35:07you know similar epics and user stories

35:10grouped together for planning purposes

35:13so an epic is Big um you would never do

35:16an epic in or pardon me a theme in a

35:20Sprint it's too big um so it's used for

35:23planning

35:24purposes below that I would put Epic

35:28epics are low

35:31priority large user

35:35stories meaning that an epic will

35:39eventually have to be disaggregated into

35:42multiple user

35:44Stories the reason it would be low

35:46priority is because if it if an epic was

35:49higher up on the product

35:51backlog um it would have to be more

35:54detailed that's when you would break it

35:55down so epics are usually going to live

35:58at the lower uh priority levels of a

36:02product backlog and as user stories are

36:05completed and the Epic rises in priority

36:08it will eventually be broken down into

36:11um more manageable user stories so great

36:14big low priority user stories then we

36:17have user stories

36:19themselves user

36:21stories are

36:24functions or

36:26features that the product owner wants to

36:28have developed a user story turns into

36:32working

36:34software that provides value to the

36:37customer and um and the product owner is

36:41the customer voice the product owner is

36:43the one who would accept or reject

36:46completed user

36:47stories and then there are

36:51tasks and a reminder when we were

36:54talking about the Sprint planning

36:56meeting we said the Sprint planning

36:58meeting is uh got two parts to it the

37:02first part is selecting all of the user

37:04stories that are going to be included in

37:06the Sprint and then disaggregating each

37:11of those user stories into

37:14tasks that's done in the Sprint planning

37:16meeting and then those tasks are the

37:18things that are actually then done when

37:21the uh work of the Sprint

37:23begins user stories can be estimated in

37:28story

37:29points or ideal days most teams favor

37:34story points they might start with ideal

37:36days but they will then usually end up

37:39going to story points um tasks are uh

37:43estimated in I ideal

37:48time which is usually hours okay so now

37:51back to our slides so at the top left a

37:55use case could be an example of a user

37:59story so it's something that um the user

38:02wants to do and how the system should

38:05support it um like um a use case could

38:10be um select and pay for items in a

38:15catalog now that could actually be an

38:18epic or maybe a theme because maybe it

38:21would get disaggregated into log on

38:25screen uh catalog uh shopping cart and

38:29checkout but the so the use case could

38:31either be a standalone user story or it

38:34could actually be uh a number of user

38:38stories um that would result from it

38:41below that requirement it could be a

38:43functional requirement a technical task

38:45or even a bug fix so I'm going to go

38:49back to the Whiteboard and a product

38:52backlog is going to have a lot of user

38:55stories that come from the the

38:58customer right whatever the customer

39:00wants

39:02then but the team may know that it has

39:04to do some development work in order for

39:07the user stories to even be able to work

39:10you know there's some system level

39:11nonfunctional requirements that need to

39:13be done and so there could be Tech user

39:17stories and then can you see this low I

39:22can't see your chats but then there

39:23could also be defect user stories there

39:27could even be risk user stories now what

39:30could happen is that um the product

39:34owner rank these in priority so this one

39:38first then that one then that one and

39:40the team says well the only thing is is

39:43that um we have to do some development

39:46work before we can actually do user

39:48story too and so what we really need to

39:52do is insert that before the uh the

39:57second priority user story and so the

40:01priority of the user stories in the

40:03product backlog while it might start

40:06with just being you know simple

40:07functional user stories coming from the

40:10uh product owner it will evolve until it

40:13includes some other things that are also

40:16considerations when it comes to uh

40:19priorities because of you know successor

40:23predecessor relationships dependencies

40:25and things like that are um

40:29considerations a user story be uh back

40:32to the the uh screen um bottom left now

40:37the user

40:38story um can use a fictitious user or a

40:42Persona to help uh the team or the the

40:48team and the product owner to get an

40:50idea of okay who's going to be doing

40:52this function uh what are they going to

40:55need in order to be able to complete the

40:57function Etc so you try and um come up

41:01with an actual well a fictitious but a

41:04person who's actually doing it to kind

41:06of get out of the realm of you know

41:08listing requirements and you know specs

41:11and things like that and say okay what's

41:12the user experience need to look like

41:14top right template a portion of a user

41:18story is um let me back up so a user

41:23story card um is usually going to

41:26contain

41:28um a brief description of the user story

41:32using some kind of a metal language

41:34format like we're suggesting right here

41:37as a user or Persona I want this feature

41:43so that I can so not unlike our um

41:49estimating session here as a frequent

41:52traveler I want to eat grapes so I can

41:55be healthier in the one that we uh

41:58didn't do uh the inventory system as a

42:02customer okay there's a a user I want to

42:06get cash back so I don't have to wait in

42:08line at the bank okay here's another

42:12user story as a consumer I want the

42:17shopping cart functionality to easily

42:20purchase items online and maybe that

42:22could be customer as well um as an

42:26executive right as a suit I want to

42:30generate a sales report so I know which

42:32departments need to improve their

42:34productivity as a buyer so you can see I

42:37I tried to come up with these different

42:38roles right here executive buyer sales

42:41rep Etc

42:44um and that's the format as a type of

42:48user I want some kind of goal um or

42:52feature and uh so that's some kind of a

42:55reason um the below that connect connect

43:00the dots by writing all of the user

43:03stories necessary to

43:05uncover the entire use case so like we

43:08were talking about right here if you

43:10want to be able to purchase items online

43:12from a catalog that might be uh multiple

43:15user stories in order to support that

43:18use case and so of course um we would

43:22want to be able to connect the dots and

43:24see where all the user stories fit in

43:26into the overall goal of the project or

43:28release and the stories

43:32um excuse

43:34me um are grouped to form an epic or

43:39higher level story so epic or theme um

43:43stories can then be split into child

43:45stories or task and so that's what we

43:47were covering before right so you have

43:50um

43:51themes up at the top that's the biggest

43:54grouping if you will used primarily

43:58for um you know high level planning

44:01purposes so you have your themes then

44:03you have your epics which are large user

44:06stories um low priority and they're

44:08going to have to be broken down into

44:11smaller user stories like in the

44:13question that we had at the end of the

44:16the last section where um the product

44:19owner needed something done and the team

44:21said well based on the size of this user

44:23story it's going to take three Sprints

44:26to do well well a user story has to be

44:29small enough to be completed within a

44:31single Sprint so a Sprint can contain

44:34more than one user story but a user

44:36story cannot stand Sprints so that

44:39feature or function that was in the

44:42question was probably more like an epic

44:45it was something that would need to be

44:47uh disaggregated into smaller users

44:51stories or perhaps it was more of a use

44:53case that would need more than one user

44:56story in order to actually deliver the

44:59overall use

45:01case let's see as a product supervisor I

45:04want to see an unfinished part

45:07list at the end of the day so that I can

45:11reallocate work the next day great user

45:14story description well done

45:17verage um did you hear that team as a

45:20product supervisor I want to see an

45:21unfinished part list at the end of day

45:23so I can reallocate work the next day

45:27that is a well-crafted description of a

45:30user

45:32story

45:33now here are some things that I want you

45:36to memorize you were hoping I was done

45:38with the memorization part so I want you

45:42to

45:44um remember that we have to invest in

45:48our user

45:49stories and I was going over to the

45:52Whiteboard and I didn't change cameras

45:54so let me do that I

45:57recommend um you know figuring out how

46:00you memorize best so that you can if um

46:06well not if you wanted to what I

46:08recommend is being able to write out all

46:11of this stuff on plain white scrap paper

46:13in about 14 minutes because that's the

46:16amount of free time you have in the

46:19tutorial when you're at the uh or when

46:21you're taking the test um exen does a

46:25little bit different you maybe won't

46:26have a too tutorial the only time you'd

46:28have a tutorial is if you were at a

46:30center taking a test um exen has other

46:33options like you can do a paper based

46:35test um uh where you get a third party

46:39you know a buddy or somebody who will

46:40agree to sort of Proctor the test for

46:43you or you can do it on your laptop all

46:45by yourself and they have software that

46:48watches you while you're taking the test

46:50and they require you to take the laptop

46:52and do like a 360 so that um they can

46:56verify that you don't have any cheat

46:58sheets up on the wall or anything like

47:00that but the point is is um you got to

47:04have this memorized um whether you're

47:06going to dump it out on the paper or not

47:09um when I took the test um I actually

47:12did the paper-based

47:13option um and that was because of some

47:16kind time constraints and it was the

47:18quickest way to get me into the test and

47:20so I didn't write out any of the stuff

47:24I'd memorized but I had it memorized and

47:26I had that memorized well enough that I

47:28could kind of recall it in my mind's eye

47:31okay

47:32so we're talking about user stories and

47:35you have to invest in your user stories

47:39you know I like memorizing things by

47:41creating these charts that have the

47:44first

47:45letter of the word or phrase that you're

47:48memorizing in a separate column and then

47:51I make up a story you know that uh um

47:55reminds me that I've got to have IV EST

47:59this one is pretty easy probably just

48:00invest Works um but so let's go over

48:05that I stands for

48:08independent

48:10independent meaning that each user story

48:13stands on its own um you don't have when

48:17we're doing scrum you don't do a user

48:20story that won't result in working

48:23software we just talked about the

48:25description of users stories right so

48:28it's a user that needs some kind of

48:30functionality for some kind of a reason

48:32and they're all independent well they

48:34work together of course they'll work

48:37together if that's the necessity but um

48:39if you developed a log on screen you

48:43could demonstrate working software for

48:45the login screen there might be another

48:47user story that is um you know has to do

48:51with displaying uh the catalog and being

48:54able to flag or select items that you

48:56want the purchase but there'd be working

48:58software for that would they work

49:00together yes but each user story would

49:03complete um or result in some kind of

49:06working software and they have to be

49:08independent

49:10negotiable negotiable in the way the

49:14user story is going to be

49:17implemented the product owner doesn't

49:19dictate to the team the team doesn't say

49:22it it's only this way and we don't want

49:24to hear anything from you so there are

49:27discussions about the size and

49:29implementation for each user user story

49:32so the product owner can't make it so

49:36detailed that there's no room for

49:38discussion and the possibility of you

49:41know the team coming up with Solutions

49:43other than what the product owner was

49:45attempting to

49:47dictate um v stands for

49:50valuable meaning each user story has to

49:53create value for the customer or the end

49:56user

49:57ER e it has to be

50:00estimable as an estimable except

50:03estimable is not really a word it's

50:06estimable um and asses for small has to

50:10be small enough to be done in a single

50:12Sprint if we're doing two we Sprints has

50:15to be able to be done in two weeks or

50:17less if we're doing four-week sprints it

50:19could be a larger user story but it

50:21would still uh have to be done in four

50:23weeks or less and then the last one the

50:27is testable every user story needs to be

50:29testable and it needs to be testable at

50:32two levels remember our triangle needs

50:35to be testable at the intrinsic quality

50:38level unit tests Etc and also testable

50:42at the extrinsic level which is the

50:45customer point of view which is

50:46acceptance so every user story uh has to

50:50be

50:52testable okay so that's invest and so

50:55let's add that to to our list of things

50:58to

50:59memorize

51:01invest and then the next one we have

51:04here is um the three C's of a user

51:08story so the first C team is

51:12card so user stories should be able to

51:17be written on a 4x6 inch index card or

51:22some uh media similar to that

51:31card the the second C is

51:35conversation the user story card is the

51:39item that is used for the team and the

51:45product owner to talk and discuss in

51:49order to make sure that the product

51:53owner and the team are on the same page

51:56when it comes to what is actually

51:58supposed to be developed and um uh what

52:04you know so what it's supposed to look

52:05like at the end which leads us to the

52:08third one which is

52:10confirmation each user story essentially

52:14has to have acceptance tests um in it

52:17itself so card 4x6 conversation that's

52:21the starting point that's where uh the

52:24team and the product owner discuss and

52:26and then eventually there will be

52:28acceptance tests included on the user

52:30story card um in order to be used during

52:35the Sprint review to um assure that it's

52:39acceptable that there's

52:41confirmation okay so oh let's add that

52:44to the memorization

52:46list

52:49so three

52:52C's all right now I've got an example

52:55here of a user story

52:59card so we're looking right

53:03here and if you were to go out on the

53:05internet and search um user story cards

53:09um they would be similar there would be

53:12some differences of course

53:16um but typically what you're going to

53:18have is you're going to have a title or

53:20a name for the user story and then

53:22there's going to be some kind of unique

53:25identifier like user story 321 then

53:28there will be the description like we

53:30just talked about as a librarian I want

53:33to have the facility of searching a book

53:36by different criteria so that I will

53:38save time while serving a

53:41customer then there might be some other

53:44descriptive words or links to other

53:46information that might be necessary and

53:49then there would be acceptance criteria

53:52or tests sometimes these get included on

53:55the back of the card but the point is is

53:57that they are on the cord on the card

54:00rather then there will be an estimate of

54:04size it could be ideal days or story

54:08points as I mentioned most teams do

54:11story points that's more likely what

54:14you'll be tested on as opposed to um

54:17ideal days but you know we'll cover both

54:20so you

54:21understand uh the

54:25differences uh there is probably it's

54:27not listed here but there's probably

54:29going to be a

54:32um value point assignment this is where

54:36the product owner um kind of determines

54:41in a relative way the uh value of the

54:44stories just like we were doing in

54:46planning poker the product owner might

54:47say well this story is twice as valuable

54:50as a as uh this other one comparing them

54:53together and this is what um these value

54:56points are what's used to uh prioritize

54:59the user stories that's supposed to be a

55:01v as in value points and then typically

55:06there's also going to be a indication

55:10sometimes it's just by colors um could

55:13be words uh that has to do with um you

55:17know where the story came from did it

55:20come from the customer that would be

55:22considered a functional

55:24requirement um if it came from the team

55:28that would be from the technical domain

55:30I'm trying to write where

55:33from uh you know it's not me team it's

55:36the

55:36mouse

55:38clearly it's hard to uh do that that's

55:42from where from um here it's got uh

55:46customer tech you could also have defect

55:49you could maybe have risk um and then

55:52there's also going to be an X

55:54Factor um which would

55:57be some kind of word probably like

56:03um stable um

56:06erratic um

56:08incomplete something like that to uh so

56:11that the team is designating the user

56:14story in uh respect to the amount of

56:17uncertainty or risk that's associated

56:19with that user story and because all of

56:22that's a part of the story right the

56:25story is going to be turned into working

56:27software there may need to be uh some

56:30efforts to actually figure out how to

56:33actually do that user

56:36story so that's the X Factor um over to

56:40the right here on the same chart we have

56:43some comments

56:45about um if you are using a software

56:50package excuse me like Trello or jir or

56:53something like that excuse me the use

56:56user story cards will generally be able

56:59to contain more information using you

57:01know dynamic links and things like that

57:05um could even include things like

57:07responsible team member or depending on

57:10how you're doing it you would break the

57:12user Story down into tasks and you might

57:14have team members assigned to various

57:17tasks for the user

57:20story um okay so that's typically what a

57:23user story card is like sometimes

57:25they're cards sometimes they're like on

57:27sticky notes and they're put up on a can

57:29band board if you're using can band to

57:31track the

57:35project if you have a story that is too

57:38large to be completed in a Sprint it's

57:41going to have to be subdivided or we

57:45call it disaggregation into um smaller

57:48user stories and there's uh three ways

57:52that we're proposing here that you could

57:54go about doing that you could split it

57:55based on operational boundaries for

57:58example as an operator one needs to

58:00manage reservations which could be split

58:03for example there could be one portion

58:05that is uh that has to do with making a

58:08reservation another one that has to do

58:09with modifying it and yet another one

58:11that has to do with cancelling it so um

58:14that could be split into in this

58:17construct here three separate user

58:19stories you could also separate based on

58:23exceptions or crosscutting concerns for

58:25example example in the beginning develop

58:29only one main path like accept repayment

58:32for a

58:33loan then address exceptions like what

58:36if a person um

58:38overpays then um come up with a user

58:41story that recognizes that and processes

58:44a refund and or gives the option of

58:48allocating the overpayment to a future

58:51payment or something like that and then

58:53also um uh um ads on other concerns like

58:59the tech access restrictions or record

59:02name of operator so maybe um you know

59:06when you're working on uh accepting

59:10payments or processing refunds it's

59:12going to check on um who the operator is

59:16or track that so that if at a later time

59:17you know who was it that gave this uh

59:20refund here well you could look and see

59:22you know okay the the operator's name

59:24was recorded or maybe you put some

59:27restrictions so that maybe not everybody

59:30um is allowed to do a refund and so you

59:34would have levels of users that have

59:36different

59:38privileges okay and then down at the

59:40bottom split Based on data boundaries

59:44for an example you know as an accountant

59:46one needs to enter balance sheet

59:49information um which could then be split

59:52into summary information and and

59:56separately um uh receivable details or

1:00:00you know maybe you could have AP you

1:00:02know so you could have different

1:00:04portions of the

1:00:05overall

1:00:07um balance sheet um activities that need

1:00:10to be done so enter AR enter

1:00:14AP

1:00:16Etc make sense so just to kind of uh

1:00:20prompt you give you some ideas about

1:00:23what to do um in a scrum project if you

1:00:27have the scenario arise where a user

1:00:29story is being estimated by the team and

1:00:32it won't fit into a Sprint it's too

1:00:35big now when it comes to determining

1:00:38value for user stories this is primarily

1:00:41owned by the uh product owner right and

1:00:45it always comes back to money but money

1:00:49you know the value can be looked at from

1:00:51different points of view so new Revenue

1:00:55obviously you know getting new customers

1:00:57and having them buy

1:00:59stuff um well below that there's another

1:01:02consideration incremental Revenue uh so

1:01:05somebody's in the process of placing an

1:01:07order um maybe there are some premium

1:01:11features that could be add-ons at that

1:01:13point in time um or maybe added later on

1:01:18so you have an existing customer who

1:01:19actually

1:01:21buys um more of or enhanced parts of the

1:01:26existing thing they already purchased or

1:01:28are in the process of purchasing

1:01:30retained value so this is

1:01:34um you know retaining customers so that

1:01:39they don't go to a

1:01:42competitor and then the bottom one is

1:01:44operational efficiency you know how

1:01:47could things be done to speed up the

1:01:51process of whatever it is um so that the

1:01:55cost of delivering uh the product is

1:02:01reduced so this then leads us to a

1:02:03discussion about priorities recognizing

1:02:06that there are some priority concerns

1:02:09that come from both the customer domain

1:02:12as well as the technical

1:02:16domain and there are some prioritization

1:02:20models um if we look right here there is

1:02:23value based prioritizing ation and the

1:02:27hierarchy of that would be high value

1:02:30followed by high risk followed by high

1:02:33value and then low risk followed by low

1:02:37value and then low

1:02:38risk so you know we might have written

1:02:41this a little bit differently but that's

1:02:42value based prioritization and this is

1:02:45primarily the product owner with maybe

1:02:47some input from the team just simply

1:02:50deciding um what he or she wants the

1:02:53most listening to the team say well you

1:02:56know there's some you know greater risks

1:02:58with this user story than that and so

1:03:01you'd probably want to uh persuade the

1:03:04product owner to take care of high-risk

1:03:06stuff first um because that would have

1:03:11an a uh oh excuse me sorry an impact on

1:03:15the future things that need to be

1:03:18done there's the K the Cano model uh

1:03:23which looks at each of the user stor and

1:03:26classifies them as being mandatory

1:03:29linear or

1:03:31exciters and the mandatory items are

1:03:34those user stories that are musts and

1:03:38they'll never move Beyond move the

1:03:41customer the end user Beyond neutral

1:03:43it's if they're not there it creates

1:03:46dissatisfaction if the the you the

1:03:49product owner and the team has done a

1:03:51good job in identifying what are the

1:03:53mandatory or threshold items

1:03:56um you would see that

1:03:59um um it just gets it to neutral that's

1:04:03what's expected for the product linear

1:04:06items um user stories are those user

1:04:09stories that as they are implemented

1:04:13progressively throughout the project and

1:04:15added to the feature set it will linear

1:04:17increase customer satisfaction and it

1:04:20can be you know in their absence

1:04:22dissatisfaction all the way up to high

1:04:25implementation

1:04:26creating a great deal of satisfaction

1:04:28for the customer and then the third

1:04:30category is exciters and

1:04:33delighters um and those are features or

1:04:36functions those are user stories that

1:04:38are not mandatory and the absence of

1:04:41them will never result in satisfaction

1:04:44going below neutral but by adding them

1:04:48um you could create excitement and

1:04:50Delight for the customer these would

1:04:53typically be things that are

1:04:57features that would be included in a

1:05:00premium version of the product or maybe

1:05:03add-ons that are promoted you know at

1:05:05the point of sale you know if you

1:05:06thought about this because it'll really

1:05:08help you or

1:05:10whatever so that's the Cano model and

1:05:13then there's weager relative waiting

1:05:15method and um this is all using numbers

1:05:20so each feature is given a value for its

1:05:25benefit

1:05:26and it's penalty given a value for

1:05:29penalty meaning what's the pain if that

1:05:31feature or function is not

1:05:34included and then there is um um the

1:05:40cost side and the risk

1:05:42side and then those are all calculated

1:05:45together and that results

1:05:49in excuse me a ranking or a hierarchy

1:05:53which gives you the uh priority for the

1:05:56user

1:05:58stories um we also talked about Moscow

1:06:01didn't we did we talk about Moscow uh

1:06:04Moscow is another prioritization model

1:06:08must

1:06:09could I said that differently must

1:06:11should could won't Moscow mscw must

1:06:15should could

1:06:17won't and we talked about that one thank

1:06:20you for that

1:06:21confirmation does it seem like a long

1:06:23time ago or is it just me I I know it

1:06:25was just last weekend but it's like last

1:06:29year okay so now let's talk about

1:06:32velocity um uh Priyanka that is exactly

1:06:36right

1:06:38um so velocity is the capacity of the

1:06:44team to

1:06:46complete work in a single

1:06:54iteration so the team has estimated the

1:06:56user stories uh for size or ideal days

1:07:01and um the Sprints are going to be three

1:07:05week weeks in duration obviously not all

1:07:08user stories can be completed in a

1:07:10single Sprint and be done with the

1:07:12project well I guess maybe I shouldn't

1:07:13say Obviously when I'm saying that I'm

1:07:15thinking well maybe you had a very small

1:07:17short duration project so you could but

1:07:20the point is is that uh it's the team's

1:07:23capacity to um complete work in a given

1:07:26Sprint and it

1:07:30is an observation it's not a prediction

1:07:34so if we're working on Sprint

1:07:38five and we're working on determining

1:07:41what our velocity

1:07:44is then um it would be the average of

1:07:48the previous four

1:07:52Sprints if there were any uh outliers

1:07:55youd you would uh disregard

1:07:58those

1:08:00um and so it's an

1:08:03observation if we look over to question

1:08:06or uh box number two here velocity is

1:08:09used to deal with um determining how

1:08:13many user stories we are going to

1:08:15include in a given Sprint and also how

1:08:19many Sprints are we going to need to

1:08:21create a release or a set of user

1:08:24stories

1:08:26and here's an

1:08:28example in box number three a team

1:08:32completed five user stories that were

1:08:36sized 5 3 8 13 and

1:08:40two two user stories each sized five

1:08:45were left half complete what is the

1:08:49velocity of the

1:08:53team and the answer is either going

1:08:55going to

1:08:57be 31 or

1:09:0036 31 is the sum of the completed user

1:09:04stories um if you were 36 you were

1:09:06claiming half of the two that were five

1:09:10uh so that would be a total of 10 so you

1:09:12claim half of it which would be five

1:09:13would take you to

1:09:1536 but it's not going to be 36 because

1:09:18the only thing that counts

1:09:20towards progress is working software so

1:09:25even if the team had finished nine out

1:09:27of 10 story points for a user story

1:09:30meaning it's almost done and then the

1:09:32Sprint ends that doesn't get counted

1:09:34towards

1:09:38velocity and you don't mess around with

1:09:41velocity um you can mess around with

1:09:43your

1:09:44estimating and you can mess around with

1:09:48um you know what user stories are going

1:09:50to be completed in a Sprint but you

1:09:53don't the the velocity is not very iable

1:09:56it is what it is based on past

1:10:01performance when it comes to levels of

1:10:04planning we have What's called the

1:10:06planning onion and let me walk you

1:10:09through this here up at the the broadest

1:10:12area is the vision level so the vision

1:10:15level that's the suits right they're the

1:10:17ones that have the strategy and

1:10:19objectives for the company and where

1:10:20it's going and so they have that overall

1:10:24big vision for the uh

1:10:27company which is likely going to include

1:10:30products and each product should have a

1:10:33road map my example of that website that

1:10:37I'm uh working on has uh three

1:10:41versions um which make up the product

1:10:43road map version one is the free site

1:10:46version two is the membership site and

1:10:49version three is the um uh the pay

1:10:54referral commissions

1:10:55uh uh version of the site and the

1:11:00product road map is then supported by

1:11:04releases so for my project I have three

1:11:07releases so all of the user stories

1:11:09needed for the free version are in

1:11:13release one all of the additional user

1:11:15stories that are needed for the um uh

1:11:20paid version the subscriber

1:11:23version uh and then also for version

1:11:25three those are all releases three

1:11:28releases and then for each Sprint we

1:11:32will be pulling user stories from the

1:11:34release that we're working on a release

1:11:37is likely going to take multiple Sprints

1:11:40and um and then the Sprints are

1:11:43populated by the individual user stories

1:11:45which are then disaggregated into

1:11:48tasks and we do the excuse me the daily

1:11:53scrum which is the daily level of

1:11:56planning and coordination so we call

1:11:58that the planning

1:12:01onion we already kind of talked about

1:12:03the release and road map um concept here

1:12:08so let's just review this quickly um

1:12:11priories high level epics and determine

1:12:13goals and releases so we'll use epics

1:12:15and themes in order to group things

1:12:17together you know what should be

1:12:18included in what release so what are the

1:12:20goals for the releases then the first

1:12:22bullet point establish goals of release

1:12:25based on market demand regulatory needs

1:12:27or customer

1:12:28expectations for each release you want

1:12:31to estimate the target

1:12:32stories repeat until the target stories

1:12:35are assigned and iteration

1:12:40length I that's it's blending some

1:12:43things here um be able to estimate

1:12:46velocity and then uh assign stories to

1:12:48the Sprints so we keep estimating the

1:12:51user stories and we keep organizing uh

1:12:54that until we can do that we can come up

1:12:56with an iteration length or Sprint

1:12:58length and then figure out what our

1:13:00velocity for each Sprint is and then uh

1:13:03assign stories to the uh the Sprints uh

1:13:07the the next bullet down iterate until

1:13:10the user stories and release date meets

1:13:13conditions of satisfaction so that's a

1:13:17definition of done or acceptance for the

1:13:18release and try not to pack too much

1:13:21into a release backlog so

1:13:28um just like you would not want to pack

1:13:31too many user stories into a Sprint you

1:13:34want to have the timelines appropriate

1:13:36and uh what are included in the uh

1:13:40events uh make

1:13:43sense okay so here's a bit more about

1:13:46release planning on this slide here um

1:13:50you've got the product backlog here on

1:13:52the left and then we might come up with

1:13:54a leas plan which could be flipped and

1:13:56could be looked at uh

1:13:58horizontally and you probably

1:14:01plan um

1:14:04about three releases in

1:14:07advance um or at least you're doing more

1:14:10of the detailed planning on that uh

1:14:12because things are going to emerge when

1:14:14we do you know Sprint one that's going

1:14:17to help in Sprint two and things that

1:14:19happen in Sprints one and two that are

1:14:20going to help um release three and then

1:14:24you've got got um you know your

1:14:26subsequent releases where we're just

1:14:28doing very high level planning it's

1:14:30called rolling wave planning where we do

1:14:32detailed planning for things in the

1:14:34future and tandem with doing high level

1:14:36planning for things in uh the future did

1:14:40I say that right detail planning for

1:14:42things in the near term in tandem with

1:14:44high LEL planning for things in the

1:14:46future um and we talked about deciding

1:14:49as late as possible I believe meaning

1:14:52that it's better to actually plan the

1:14:54later

1:14:55uh

1:14:57releases uh for purposes

1:15:01of uh making sure we have more

1:15:04information uh the most information

1:15:07available okay so

1:15:11estimation let's start at the top left

1:15:13the principles behind estimation

1:15:16understand the cone of uncertainty which

1:15:18is an estimate or best guess to begin

1:15:22with and then progressively becomes more

1:15:24accurate it in fact let's just take a

1:15:27break and look at the cone of

1:15:28uncertainty so at the very beginning of

1:15:31a project there's going to be a high

1:15:33level of

1:15:34uncertainty um if I were to draw this

1:15:37chart I would make it a little bit more

1:15:42like

1:15:44this so clearly you're going to drisk

1:15:48the

1:15:50project as early as you can and then

1:15:53eventually all risk appears when the

1:15:55project is done risk is

1:16:01uncertainty okay below that the only

1:16:04estimate that matters is the one given

1:16:08by the

1:16:10team supported by this uh comment here

1:16:14nothing is impossible for the one who

1:16:16doesn't have to do it so the product

1:16:19owner is like team come on you can do

1:16:21this the team's like no we know what our

1:16:24velocity is no oh the product owner says

1:16:26I'm telling you there's no way that that

1:16:28can't be done I know you can do it I

1:16:30trust you I believe in

1:16:32you but the product owner doesn't have

1:16:34to do have to do the work okay top right

1:16:37overestimation and underestimation is

1:16:40always going to be an issue that we deal

1:16:42with it's more likely that we will

1:16:46underestimate than

1:16:49overestimates and by looking at our

1:16:52velocity from iteration or Sprint to

1:16:56Sprint um there could be some

1:16:59information that is um showing us that

1:17:04we're underestimating for example

1:17:07meaning um we're thinking we you know

1:17:09the user stories are smaller than they

1:17:11are and that we can get you know a

1:17:13certain number done in the Sprint and

1:17:15then there's a fail well that would mean

1:17:17then that would be discussed during the

1:17:20retrospective and then we would do

1:17:22something different going forward which

1:17:24might include doing some reestimating

1:17:27scrum estimating is not necessarily more

1:17:31difficult however scrum exposes bad

1:17:33estimates sooner which is a good thing

1:17:36when we were doing our um uh planning

1:17:40poker you could see that um the first

1:17:43time as a team you know we didn't know

1:17:46each other we didn't know everybody's

1:17:47thoughts and concerns and those kinds of

1:17:51things you know get shared and absorbed

1:17:53as a project goes goes on and so there's

1:17:55a higher awareness of that so um what we

1:17:59would say is that um using estimation

1:18:04techniques scrum estimation techniques

1:18:07might be um more inaccurate at the

1:18:10beginning of a project but they will

1:18:12quickly become very accurate as the um

1:18:16project advances

1:18:20forward let's see is there a question

1:18:22here can velocity be increased over a

1:18:25period of time for the project yes it

1:18:28can now it's not that it can't it will

1:18:32increase if the team is learning how to

1:18:34work together better and better you

1:18:36would expect that if I can just use my

1:18:39mouse here if we were

1:18:41tracking velocity so this would be um

1:18:47points completed over here uh let me

1:18:51just do pts for points and down here is

1:18:59time and we go from Sprint to Sprint

1:19:02right you would expect that maybe you

1:19:05know the first couple of Sprints the

1:19:07team would be learning how to work

1:19:08together and there would be a steep

1:19:10curve and then it would kind of flatten

1:19:12out and maybe have you know a slow rise

1:19:16going forward as the team emerges as a

1:19:20high performing team they get better at

1:19:22their cross uh function

1:19:25Behavior you know somebody's sick the

1:19:27team just keeps chugging along um other

1:19:30things you know just um oh

1:19:34sorry there I bumped the thing on my

1:19:37screen there

1:19:40um um so the team you know learns how to

1:19:43work better together and you know their

1:19:46estimates become more accurate Etc and

1:19:49you would expect a high per a high

1:19:51performing team to have a uh

1:19:55a result like this for velocity where

1:19:57there's quick Improvement and then it

1:19:59kind of stabilizes and then begins to

1:20:01tick

1:20:03upwards okay we talked about the cone of

1:20:06uncertainty let's talk about ideal time

1:20:10um when we do estimating for user

1:20:15stories um we do it in ideal days when

1:20:19we do estimating for tasks we do it in

1:20:22ideal time which means hours I think

1:20:25that's on the Whiteboard or it was on

1:20:26the Whiteboard oh it was on it um so

1:20:31ideal time is the amount of time it

1:20:35takes to complete a piece of

1:20:43work but that's based

1:20:46on the notion

1:20:49that the team member or members are

1:20:52available to do just the work work with

1:20:57no distractions or anything at all so

1:21:01assuming that um prian could sit down

1:21:06add a keyboard and code for eight hours

1:21:10without taking a break for lunch no

1:21:12phone calls no discussions no meetings

1:21:15of any kind just work eight hours how

1:21:18much could be done in that eight hours

1:21:20by prianka that's what ideal time is but

1:21:24the thing of it is is that there is no

1:21:26such thing as somebody being able to

1:21:28spend every minute of every day only

1:21:32doing work there will be um

1:21:35distractions so it has to be converted

1:21:39into a lapse time now we don't convert

1:21:42it to a lapse time at the user story

1:21:44level but we do convert it to a lapse

1:21:47time when we are dealing at the task

1:21:49level and what that looks like is you

1:21:54know for each team member you're going

1:21:55to have to do it separately because some

1:21:57team members have more distractions than

1:22:00others some might have other duties that

1:22:03pull them away um whatever the case may

1:22:06be um you determine how much time in a

1:22:10given day a team member is available to

1:22:13do work so say it's five hours out of

1:22:15eight for one maybe it's six hours out

1:22:19of eight for another maybe it's four out

1:22:21of eight but you figure out what it is

1:22:23and then you you take the average and

1:22:27that average availability is used then

1:22:29to convert Ideal Time into elapse

1:22:35time um I should have circled this box

1:22:38here because we talked about this as

1:22:39well um and then I already mentioned

1:22:42this here only considers actual work

1:22:44time not the distraction so that's the

1:22:46concept of Ideal time when it comes to

1:22:50story points it's different than that

1:22:53they are a measure of size relative to

1:22:57each other so we were doing planning

1:23:01poker this morning where um we were

1:23:04looking at grapes versus apples and then

1:23:06we were looking at oranges and and what

1:23:09else do we have watermelons and coconuts

1:23:11and we weren't trying to figure out how

1:23:14much time it would take to eat grapes as

1:23:16opposed to how much time it would uh

1:23:18take to eat a coconut it's clear that

1:23:21it's going to take longer to eat a

1:23:23coconut because there's more effort

1:23:24involved so we have a sense that it's

1:23:26going to take more time but comparing

1:23:28the coconut to our Baseline of two right

1:23:32we came up with a baseline of two for

1:23:34the smallest user Story We compare

1:23:37eating coconuts to that Baseline and we

1:23:39say okay you know what it's going to

1:23:40take more effort to uh eat the coconut

1:23:43than it is to eat grapes or

1:23:49apples um so you can do it like we did

1:23:52you can also triangulate

1:23:54um for example when we did our planning

1:23:57project this morning or this morning for

1:23:59me rather at the

1:24:02beginning um oh that's not it that is

1:24:05the daily standup here it

1:24:09is if I had said Team I want you to pick

1:24:13a small user story a medium user story

1:24:15and a large user story um and then we

1:24:19would then compare other stories to

1:24:21those three and so we would kind of

1:24:22triangulate on it

1:24:25um let's say that we did uh you know two

1:24:28was

1:24:29small U I'm sorry I'm saying that wrong

1:24:32grapes was small apples were medium and

1:24:35coconuts were large well if we then

1:24:38looked at Orange and we said well you

1:24:40know orange

1:24:42is um smaller than Apples but bigger

1:24:46than grapes so we would know this would

1:24:49fit in between grapes and

1:24:51apples um and and so let's say you know

1:24:55we had apples at five and grapes at two

1:24:59then we would say an orange is probably

1:25:01going to be

1:25:05three and the values you know now I used

1:25:09um in our example the modified Fibonacci

1:25:13series uh what we do in scrum and agel

1:25:15if we're using story points we're going

1:25:18to use um a nonlinear scale for the

1:25:22values so down at the Bott

1:25:25bottom here there's the modified

1:25:27Fibonacci Sequence the way the Fibonacci

1:25:30sequence works by the way

1:25:33um um it's

1:25:37the the value is the sum of the two on

1:25:41the right so let me break this right

1:25:43here because this is a modified

1:25:45Fibonacci so 13 is 5 + 8 8 is 3 + 5 5 is

1:25:502 + 3 and 3 is 1 + 2 if we were doing

1:25:55the real Fibonacci series this wouldn't

1:25:57be 20 it would be 13 + 8 which would be

1:26:0021 um I I don't know why some use

1:26:03modified Fibonacci and others not but

1:26:06that's just kind of a common thing to do

1:26:09if you're doing planning poker you give

1:26:11everybody seven cards 1 two 3 5 8 13 and

1:26:1520 um another nonlinear scale is

1:26:18doubling 1 12

1:26:20486 um you typically don't go too far to

1:26:23the left with values because um that

1:26:26either means that you're being too

1:26:27granular or you've got stories that are

1:26:29probably too big and they need to be

1:26:33disaggregated now somebody just chatted

1:26:35here um should some buffer time be

1:26:38included in the actual

1:26:41estimates

1:26:43um let me answer that question first by

1:26:46going back to Ideal time and then I'm

1:26:47going to come back to story points and

1:26:49answer the question when we're

1:26:51estimating in Ideal Time time we don't

1:26:55add a special amount of time that we

1:26:58would call a buffer we just allow for

1:27:01the distractions and the interruptions

1:27:03which could look like a buffer right

1:27:05you're saying you know um you know

1:27:08Priyanka if um based on your duties in

1:27:11the

1:27:12organization and our uh work day of

1:27:16eight hours you're typically available

1:27:18to be doing your project work five out

1:27:21of those eight hours so when we are

1:27:24converting ideal time to elapse time um

1:27:28you know we will be building in extra

1:27:30time based on distractions and

1:27:32interruptions we would not call it a

1:27:33buffer but that's essentially what we're

1:27:35doing now when it comes to user stories

1:27:39that we're using story points it is

1:27:42different um the points are for the

1:27:46entire amount of the work and why might

1:27:49we need to have some extra time for a

1:27:51user story well it's likely going to be

1:27:54driven by uncertainty there might be

1:27:56other uh things that impact it but

1:27:59that's the main

1:28:02thing sorry

1:28:05team so when the team is estimating the

1:28:08size of the user story they will be

1:28:12including in their discussion and

1:28:14estimates any extra time or buffer time

1:28:17that would be needed for uh that user

1:28:20story to be completed so do we

1:28:25accommodate um uncertainty when we're

1:28:27using story points yes we're looking at

1:28:29the The X Factor and if we've got an

1:28:32unstable user story then we're probably

1:28:35going to um say you know this is going

1:28:38to be a bigger user story than one

1:28:40that's similar but has a a much lesser

1:28:44level of

1:28:46uncertainty um so that's the story

1:28:49points let's compare the

1:28:52two um I time uses things like hours and

1:28:57days which is easier to explain outside

1:28:59the team right the suits like things in

1:29:02days and hours everybody's estimate may

1:29:05be different not a bad thing it's easier

1:29:07to do at the beginning because we're

1:29:09oriented to think about time um and it

1:29:12does kind of shine a light on wasted

1:29:15time story

1:29:18points um are harder to explain outside

1:29:21the team um you know the suit says well

1:29:25um how long is it going to take to do

1:29:27user story 301 and our answer is um well

1:29:32that's a 10 user story Point user story

1:29:35and the suit saying what does that mean

1:29:37tell me how long it's going to take um

1:29:41so the suits have to be converted to uh

1:29:44uh story points now here's the thing

1:29:48it's a lot easier to get consensus when

1:29:51we're estimating in story points and and

1:29:54once we get good at it it's going to be

1:29:56much

1:29:57faster we have to remember it's not

1:30:00comparable across teams so you know a

1:30:03team working together will have its own

1:30:06kind of system for sizing the stories

1:30:09and another team that might even be

1:30:11working on the same project will have a

1:30:13CO a whole different uh scheme and so if

1:30:16the velocity of one team is 25 and the

1:30:19velocity of another is 50 it doesn't

1:30:22mean that the team with the velocity of

1:30:2450 is able to do more work than the

1:30:26teams whose velocity is

1:30:3025 and we did um when we got our day

1:30:34going um we started with um uh a

1:30:38planning poker exercise and so you know

1:30:41we used all of the team members so we

1:30:44selected the team the product owner was

1:30:46there to answer any questions um the

1:30:50team discussed each of the story cards

1:30:52and then uh decided what their vote was

1:30:55going to be and then everybody voted at

1:30:57once if there were outliers they were

1:30:59discussed and um the reasons for that uh

1:31:04those variances those outliers um were

1:31:07then part of the discussion and then we

1:31:09did another round of voting and we would

1:31:11keep doing that until we had our

1:31:13estimates converge or we reached

1:31:15consensus on

1:31:18them okay so advantages of planning

1:31:21poker it's fun it's quick it gets the

1:31:24whole team involved the the team

1:31:27understands um a little bit about all of

1:31:30the stories everybody contributes his or

1:31:33her expertise and the discussion during

1:31:35the estimation provides Clarity in the

1:31:37direction approach and even a bit of

1:31:40design if we were in the same room team

1:31:42and we were doing a planning poker

1:31:44activity like we did uh at the beginning

1:31:46of our day uh together um we would be

1:31:50able to you know model it a little bit

1:31:52better or if we tried to unmute

1:31:54everybody but you could hear the

1:31:56background noise I've tried doing it it

1:31:57doesn't really work but you get the idea

1:31:59that if the team's discussing and things

1:32:01like that you would actually get to the

1:32:03point where um your estimates would

1:32:05converge and the team would say okay

1:32:07this user story size is you know

1:32:10whatever it

1:32:11is okay so we need to wrap things up for

1:32:14the day so we are ending right here and

1:32:17that means tomorrow when we get together

1:32:19we're going to be doing slide 20 you're

1:32:22starting with that which is Affinity

1:32:25estimating and let's see Affinity

1:32:27estimating we go through that we're

1:32:29going to talk about tracking progress

1:32:32using um information radiators and then

1:32:37we're going to talk about what we do

1:32:39when we find variances between the plan

1:32:42and the actual results and then we'll

1:32:43have our quiz now let's talk about the

1:32:46values of scrum now this is different

1:32:48than pillars this is um values so there

1:32:51are five um um values for that

1:32:57and this is something that I want you to

1:32:59memorize so I'm going to switch my

1:33:01cameras here and go to the white

1:33:03port and we're going to

1:33:06add to our

1:33:13list Oh wrong

1:33:16color you can tell I'm a project manager

1:33:18because that would bother

1:33:20me so the five

1:33:25values of

1:33:29scrum and there's an acronym you can see

1:33:32that on the screen right C

1:33:40Force okay so

1:33:44five values of

1:33:48scrum and c f o r r

1:33:55c and you kind of know my style here you

1:33:58don't have to do it this way you know

1:33:59whatever works for you but have some

1:34:02kind of a strategy for memorizing things

1:34:05will probably serve you

1:34:08well so the um the first C is

1:34:14commitment the next one there are four

1:34:17four F is

1:34:22focus o is

1:34:26openness is that two ends or one I don't

1:34:30know

1:34:31openness we'll blame it on the marker if

1:34:33it's not right um R is for

1:34:38respect and the last C

1:34:43is

1:34:44courage and so there's your little chart

1:34:47right there and um let me just briefly

1:34:51go over these

1:34:56um none of these will be a big surprise

1:34:58here um we've talked about some of them

1:35:00already in one context or

1:35:04another um so the for commitment that

1:35:09means the commit the team is going to

1:35:11commit to deliver value to the

1:35:13customer um they're on board there's the

1:35:16Buy in all of that's there Focus the

1:35:19team is going to focus on the few

1:35:22important things

1:35:25um at a time so we're going to do time

1:35:29boxing uh we're not going to do things

1:35:31broadly specifically uh focus on a few

1:35:34things at a time o is openness that's

1:35:37analogous to the T transparency and the

1:35:40pillars meaning we're going to be

1:35:42completely open in

1:35:44Sharing um information about the project

1:35:47our own opinions our fears our concerns

1:35:51Etc R stands for respect and that's kind

1:35:54of a

1:35:55360 view we respect ourselves we respect

1:35:58others we respect the uh Concepts that

1:36:02we are using as part of scrum and

1:36:08um um and you and we respect the other

1:36:11stakeholders as well 360 and the last C

1:36:14stands for courage and that's the

1:36:16courage to make commitments uh even when

1:36:20we're in an uncertain environment

1:36:25um courage to deal with um fear that

1:36:29comes from a failure uh courage to uh

1:36:33share disagreements openly yet

1:36:36respectfully um courage to participate

1:36:39in debating technical approaches

1:36:43Etc okay so now let's go to the scrum

1:36:47life cycle chart and what I want to do

1:36:49is I want to elaborate on this just a

1:36:52little bit

1:36:54and I'm going to try and use my mouse to

1:36:57do some some uh additions to this um

1:37:03first of all we have the product backlog

1:37:06the product backlog has to be kept

1:37:08current and we call that grooming

1:37:12grooming is adding user stories and

1:37:15removing user stories from the product

1:37:18backlog product backlog is the scope of

1:37:20the project the product owner owns that

1:37:22the team is assists in that effort

1:37:26related to grooming is pruning pruning

1:37:29the backlog is prioritizing and

1:37:32reprioritizing so the product backlog is

1:37:35pruned and groomed regularly throughout

1:37:38the course of the project

1:37:42now there is a meeting that takes place

1:37:45right here which is called the

1:37:49Sprint planning meeting can I just do PP

1:37:53here Sprint planning meeting okay that

1:37:56is one of the ceremonies or events that

1:38:01um takes place in scrum in the um the

1:38:07Sprint planning

1:38:09meeting it is a Time booxed Event and it

1:38:12is time boxed to two hours for each week

1:38:16of the Sprint so in our example here we

1:38:19have a 30-day Sprint so if we have a

1:38:224-week Sprint

1:38:24then our Sprint planning meeting will

1:38:26be8 hours in

1:38:28duration and two things happen during

1:38:30the Sprint planning meeting the user

1:38:33stories that are going to be included in

1:38:35the Sprint are selected right they're

1:38:38put into the Sprint backlog which is a

1:38:42subset of the product backlog containing

1:38:44the user stories that are going to be

1:38:45completed during the Sprint and the

1:38:48second thing that happens during the

1:38:50Sprint planning meeting is the selected

1:38:52users stories are then disaggregated

1:38:56into tasks and

1:39:00estimated once that's done then the work

1:39:04of the Sprint begins there will be a

1:39:07daily scrum like we did at the beginning

1:39:10of our work day together as our team and

1:39:15then at the end of the work of the uh

1:39:19Sprint there will be the Sprint re

1:39:24RW the Sprint review meeting or ceremony

1:39:28is also time boxed and it is time box to

1:39:32one

1:39:33hour for each week of the Sprint so if

1:39:36we're doing a four-week Sprint the

1:39:38Sprint review meeting would be 4 hours

1:39:42in length the primary purpose of the

1:39:45review is to Showcase and demo the

1:39:48software and get feedback from relevant

1:39:51stakeholders and allow the the product

1:39:54owner to say I accept or I reject the

1:39:56work that has been

1:39:59done then after that is the Sprint

1:40:04retrospective now this is where the

1:40:08team asks and answers three questions

1:40:12what went well what did not go well and

1:40:15what are we going to do different going

1:40:17forward regarding the previous Sprint

1:40:21that was just completed and the ones

1:40:23that is is just coming

1:40:26up um and then the uh the Sprint itself

1:40:30will result in working software or value

1:40:34for the customer and then of course

1:40:36everything goes back and repeats for as

1:40:38many Sprints uh as necessary to complete

1:40:43the scope of the

1:40:46project um let's see I see a chat here

1:40:49how similar or different is a product

1:40:51backlog to SRS software requirement

1:40:54specs document which is widely used in

1:40:57projects um it's different um and if you

1:41:01will hang on to that question um we're

1:41:04going to have a discussion later on

1:41:06about user stories and that will help

1:41:08you understand uh the differences um and

1:41:13we'll get into the user stories that

1:41:15come from the customer and user stories

1:41:17that come from the text domain and that

1:41:20will help answer your question so you

1:41:22okay hanging on to that

1:41:25okay great

1:41:26thanks okay so um a little bit more

1:41:29detailed view of the scrum Project Life

1:41:31Cycle now let's talk about a couple

1:41:34other things here when it comes to um a

1:41:39Sprint there are some things that affect

1:41:42the duration of the Sprint so the team

1:41:45is going to have to decide how long each

1:41:48of the Sprints are going to be and

1:41:50things that are a factor include the

1:41:52stability of the product backlog If the

1:41:55product backlog is changing a great deal

1:41:58um then that's going to argue for

1:42:01shorter

1:42:03durations um because there's uh a high

1:42:06level of uncertainty and so you have a

1:42:09greater amount of control on your

1:42:12project if you have shorter Sprints now

1:42:15on the other hand another factor is the

1:42:18cost of

1:42:19iterating every time we do a Sprint

1:42:21there are costs associ ated with the

1:42:24Sprint planning meeting the Sprint

1:42:27review the Sprint retrospective right

1:42:30people show up to those meetings you got

1:42:32to pay them and um excuse me so there

1:42:37there is an overhead cost to actually

1:42:41doing sprints the goal of the Sprint is

1:42:44working software at the end the end

1:42:48product should be near releasable or

1:42:50potentially shippable now there might

1:42:53working software that the product owner

1:42:56isn't going to want to release um maybe

1:43:00because it as a standalone component of

1:43:03working software for the system doesn't

1:43:06create any value or any usability for

1:43:08and users uh and maybe you wait till the

1:43:11end of a release before you release

1:43:14everything but the idea is is this

1:43:16working software and it could be

1:43:18released if um the customer wanted to do

1:43:22that

1:43:26um sorry I just dropped

1:43:31something I see a question there I will

1:43:33Circle back to your question in just a

1:43:35sec um the Sprint duration and

1:43:39deliverables do not change once the team

1:43:41has committed this is another one of

1:43:44those things that has to be viewed as

1:43:47absolute when we're doing scrum so if we

1:43:50say that we're going to do a two week

1:43:53Sprint and we select five user stories

1:43:56based on our velocity or capacity once

1:44:01that decision has been made the duration

1:44:03of the Sprint does not change and we do

1:44:06not add or remove any user

1:44:09stories now it could be possible for the

1:44:13product owner to cancel a Sprint but

1:44:16that would be extreme that would be

1:44:19because there is such a major change to

1:44:23the product backlog that the work of the

1:44:25current Sprint is going to be completely

1:44:28irrelevant you don't change the Sprint

1:44:31you cancel the Sprint and then the

1:44:33bottom one here the Sprint begins with

1:44:35planning and ends with review and a

1:44:37retrospective and there was a question

1:44:39here are there any issues with combining

1:44:41the retrospective and the planning

1:44:43ceremonies and the answer to that is yes

1:44:46now could they be combined depending on

1:44:49the environment the answer is yes and

1:44:51the way we would arrive but whether or

1:44:53not it would make sense is who's going

1:44:55to be

1:44:57participating um but they would be

1:45:00separate agendas so the agenda for the

1:45:03retrospective is what went well what did

1:45:06not go well what are we going to do

1:45:07different and the mandatory participants

1:45:10for that meeting are the the the team

1:45:13the scrum team is the scrum Master going

1:45:17to be there likely as a facilitator um

1:45:20is the product owner going to be there

1:45:23maybe maybe not if the product owner is

1:45:25there you know the product owner could

1:45:27maybe answer questions and help clarify

1:45:30but the product owner does not weigh in

1:45:33on what went well what did not go well

1:45:35and what are we going to do differently

1:45:36that is all owned by the team in the

1:45:39planning meeting the product owner has

1:45:41to be there and the product owner is the

1:45:44main driver of that meeting um the

1:45:46product owner is talking about or

1:45:49dealing with the priority of the user

1:45:50Stories the teams weighing in maybe

1:45:53there's some dependencies that need to

1:45:54be considered but um the product owner

1:45:58has to make the hard decisions with

1:46:00regards to what's going to be done in

1:46:02the next Sprint based on the constraints

1:46:04from the team like velocity um and

1:46:08technology and sequencing and things

1:46:10like that so um I kind of answered that

1:46:14from a real world point of view yes it

1:46:16could be it's not desirable on the test

1:46:19they are completely separate

1:46:23did I get you

1:46:24there I'll keep my eye on the chat box

1:46:27make sure I got that answered well

1:46:29enough for you and let's move

1:46:33ahead okay the Sprint planning meeting

1:46:36this is uh looking right down here this

1:46:38is conducted at the beginning of a new

1:46:40Sprint it's attended by the team the

1:46:42product owner and the scrum master and

1:46:45there are two approaches to deciding

1:46:47what's going to be included in the

1:46:49Sprint it can be based on commitment and

1:46:53it can also be based on

1:46:57velocity and the goal here is to get

1:47:01team Buy in make sure that there is um

1:47:05Clarity between the team and the product

1:47:09owner as to what the definition of done

1:47:13looks like for the user stories that are

1:47:15going to be included in the

1:47:17Sprint and um of course it should be

1:47:20realistic and achievable and you know

1:47:23there can be a little bit of of um an

1:47:27issue where you've got you know a

1:47:28well-meaning product owner that's

1:47:30driving really hard and the team says

1:47:33you know we can do these Sprints and the

1:47:35product honor is saying no come on you

1:47:37got to do at least one more I got to

1:47:38have this one in this Sprint um you

1:47:41could get a question like that and it

1:47:42might be what would the scrub Master do

1:47:45if you had a dominant product owner

1:47:47that's trying to persuade the team to do

1:47:49more than the team thinks it can do

1:47:53um and that's where the scrum Master

1:47:55comes in the scrum Master plays the role

1:47:58of the mentor the coach and uh you know

1:48:01assisting in the resolution of those

1:48:02kinds of issues without deciding the

1:48:05scrum Master is not a decider the team

1:48:08decides uh when it comes to how and the

1:48:12product owner decides when it comes to

1:48:14what okay the scrum meeting uh daily

1:48:19scrum we've talked about it right the

1:48:21entire team attends the meeting could

1:48:23the product owner be there yes does the

1:48:26product owner need to be there no

1:48:28sometimes the product owner can be uh

1:48:31you know an impediment to the meeting um

1:48:34but would be welcome but if the product

1:48:36owner started asking questions or became

1:48:38the focus of questions being asked uh

1:48:41the scrum Master would have to help

1:48:43facilitate a change because um that

1:48:46would not be effective for the daily

1:48:48scrum duration 15 minutes we talked

1:48:50about that and the agenda what did I do

1:48:53yesterday what am I going to do today

1:48:54and what are my

1:48:57impediments the Sprint

1:48:59review now who attends it's going to be

1:49:02the team the product owner the scrum

1:49:04master and potentially others

1:49:08so optionally others you know that we

1:49:11would want to get feedback from would be

1:49:14end users um operations folks Pursuits

1:49:18um all of those would be welcome

1:49:20depending on the relevance of the

1:49:23software that's being demoed and being

1:49:26um uh subject to the acceptance testing

1:49:30and the product owner you know giving

1:49:32the thumbs up or the thumbs down when it

1:49:34comes to acceptance the duration for

1:49:37this we mentioned this before it's not

1:49:39just a flat two hours it's one hour per

1:49:42week so if you did a four-week Sprint

1:49:46you would plan on the review being a

1:49:48maximum of 4 hours in duration the

1:49:51agenda is to demo the completed software

1:49:55get feedback and then see where we are

1:49:58when it comes to the the release plan

1:50:02the retrospective who is there it's

1:50:04attended by the team and I would modify

1:50:07this slightly and I would say this is

1:50:10the the mandatory group that needs to be

1:50:13there um optionally the scrum Master

1:50:15would be there potentially you could

1:50:17have an external facilitator the role of

1:50:20the scrum Master would be the

1:50:21facilitator

1:50:23now um a good scrub Master being a

1:50:26facilitator in a retrospective would

1:50:29have some knowledge of control charts

1:50:32the five

1:50:33y's um um Ishikawa diagrams things like

1:50:38that and although the scrum Master would

1:50:40not be participating in the actual use

1:50:43of the tools the scrum Master would be

1:50:45facilitating the effective use of those

1:50:49tools um when it comes to duration the

1:50:52rule is 45 minutes for each

1:50:56week oo that was a good four that was

1:50:59kind of a lousy

1:51:01five so if you had a uh two week um uh

1:51:07Sprint then you would have an hour and a

1:51:09half retrospective

1:51:12Max and what's the purpose there's H the

1:51:15agenda for the retrospective three

1:51:17questions what worked well what did not

1:51:19go well what are we going to do

1:51:20different and it's not just chat session

1:51:23while that would be part of it you will

1:51:25use tools and techniques um like some

1:51:28that I mentioned control charts

1:51:31um Ishikawa

1:51:34diagrams

1:51:36um five wise there's a number of things

1:51:38that you might use uh in order to

1:51:42surface uh assignable causes for issues

1:51:46so that we could then come up with a

1:51:48resolution to

1:51:49those um this is where continuous

1:51:53Improvement um is uh going to happen um

1:51:57you know continuous Improvement is the

1:51:59result of other things but this is the

1:52:01main thing and if you were get a

1:52:02question about the relevance or the

1:52:04necessity of retrospectives there is no

1:52:06equivocation you do a retrospective

1:52:09after every Sprint um if you don't do a

1:52:12Retros um if you don't then um there's

1:52:16no

1:52:18improvement um you know things just stay

1:52:21static okay so we talked about the four

1:52:24main ceremonies right in uh a scrum

1:52:28project Sprint

1:52:30planning you with me daily standup the

1:52:34Sprint

1:52:36review and then the Sprint

1:52:40retrospective all considered mandatory

1:52:43for effectively doing scrum and not

1:52:46doing them uh or one of them would be

1:52:49considered a sale

1:52:53okay artifacts that we use when it comes

1:52:55to scrum uh we've talked about the

1:52:59product backlog we talked about the

1:53:01Sprint backlog there's also um a release

1:53:04backlog uh depending on the size of the

1:53:08project it might be advisable to uh

1:53:11group user stories into releases um if

1:53:15you have a product road map uh your

1:53:18releases would line up for that um for

1:53:22example

1:53:23I've got a um uh a real life project

1:53:26that I'm working on and my product road

1:53:29mapap is um uh got three versions it's a

1:53:33website um the first uh version is free

1:53:37uh the second version includes a

1:53:40membership component and the third uh

1:53:43version includes um a referral

1:53:47commission uh portion to it and so I

1:53:50will then uh do three releases I'll have

1:53:54all the user stories that will result in

1:53:56version one all the the user stories

1:53:59that result in version two so that's

1:54:02what the release uh backlog is and so if

1:54:05you look at it in sequence the product

1:54:07backlog is the overall scope of the

1:54:09project the release backlog is a subset

1:54:12of the product backlog and then the

1:54:14Sprint backlog would be a subset of the

1:54:16release

1:54:18backlog the product backlog might look

1:54:20something like this

1:54:23um it's a list of user stories that are

1:54:27written by the product owner and are

1:54:29going to be developed by the um team

1:54:33members and didn't we have we had a

1:54:36product backlog

1:54:39for the thing that we did this morning

1:54:41right so here's another example of a

1:54:44product backlog um this is more of a

1:54:49list um it just has the title there

1:54:52would be a user story card for each of

1:54:55the items in the product

1:54:58backlog um but the idea would be it

1:55:00would be prioritized uh there could be

1:55:03user stories that are added or removed

1:55:06depending on what the product owner

1:55:08wants product owner owns the product

1:55:11backlog um that's a given uh does the

1:55:15product owner create all the user

1:55:17stories for the product backlog in

1:55:20isolation no absolutely absolutely not

1:55:23because there are technical

1:55:25considerations that the product back or

1:55:27the product owner might not um even

1:55:29consider the product uh owner's

1:55:32perspective is more the customer side

1:55:35the end user side um and so the product

1:55:39owner might not even think of things

1:55:41like security or architecture related

1:55:44things um and there might even be uh

1:55:48user stories that come from the

1:55:50technical domain that need to be

1:55:52uh developed before some of the uh

1:55:56products owners user

1:55:59stories another artifact is the

1:56:01definition of done the definition of

1:56:04done is primarily a

1:56:07checklist and this is what forms the

1:56:10agreement between the product owner and

1:56:13the

1:56:14team um as to when we consider something

1:56:19completely

1:56:20done and if we look down here it's um uh

1:56:27where's my I'm looking for my cursor it

1:56:29says here it's usually prepared by the

1:56:31scrum master in consultation with the

1:56:34team

1:56:36um that is I would modify this slightly

1:56:41um the definition of done is really

1:56:43driven by the team the see the scrum

1:56:46Master is never a decision maker if you

1:56:49have a scrum Master that's saying we

1:56:50have to have this in the definition have

1:56:52done then that's an infringement on the

1:56:55empowerment of the team I agree that

1:56:58this the scrum Master is a part of the

1:57:01effort to develop the definition of done

1:57:04um but I would kind of flip that uh the

1:57:07scrum Master is the facilitator it's the

1:57:09team that still um owns that so um now

1:57:14is the product owner involved in this

1:57:17absolutely because the product owner is

1:57:19involved in defining the store and what

1:57:22a fully implemented story looks like so

1:57:26here's a

1:57:28list a short list of what a definition

1:57:31of done could look like the story has

1:57:34been fully implemented or the code

1:57:37completed as

1:57:39described um automated unit tests have

1:57:42been developed with at least 80% code

1:57:45coverage um it could be more than that

1:57:48um this is just an example automated

1:57:50unit test and acceptance tests of the

1:57:53story are passing no severity has one or

1:57:57two

1:57:59defects and then high priority test

1:58:02cases have been automated and added to

1:58:03the regression

1:58:05Suite um the definition of done we point

1:58:08out is likely to evolve as the team's

1:58:11maturity increases as the project

1:58:16advances there are three distinct roles

1:58:19in scrum the scrum master the product

1:58:22owner and the development team the scrum

1:58:25Master assists both the development team

1:58:28and the product owner the scrum Master

1:58:30works with the product owner to maximize

1:58:33return on

1:58:34investment the scrum Master empowers the

1:58:37development team by fostering creativity

1:58:40removing impediments and coaching and

1:58:42mentoring as appropriate the product

1:58:45owner is responsible for project success

1:58:47by defining the project Vision

1:58:50requirements and priorities

1:58:53the product owner has to resist the