200 AGILE PMP Questions and Answers - the BEST Preparation for the Exam!

[Music] hi everyone i'm so glad you're here we're going over 200 agile questions ideal for preparing for your pmp exam or your agile certified practitioner exam or any other agile style exam that you're going for it will also give you great tips for handling the exam as we look through the way that we answer each question but this is all of the questions put together in one video for you we filmed it over many many weeks and here they are all together just so you can see them all in one place i really hope you

enjoy and get a lot out of it and i can't wait to spend this time with you let's get into the questions the first question you're working as an agile project manager and the executive manager who will own the product so potentially the product owner maybe you're delivering would like to focus primarily on only set processes and tools to manage the project okay this sounds sort of in direct competition to agile or opposite to agile so let's see what we're going to say what would you recommend to them instead of set processes and tools well

we could focus on the definition of success as defined by the project manager uh i mean maybe but usually the product owner they're sort of the customer that we're working towards so they're they're who we really want to please in this situation so maybe not that one we focus primarily on the individuals and interactions involved that's got potential because that's part of the agile manifesto as well focus primarily on the scope of the project probably not in an agile scenario and focus primarily on the schedule of the project these two things are important in a

normal project management situation like a waterfall potentially but for agile we tend to focus on the individuals and the interactions we form or make self-forming teams if we can around people who really believe in the product and really want to get it done and we focus on those individuals and the interactions like stand-ups and retrospectives and improving the the processes and situation as well so let's go with letter b for now answer b agile manifesto recommends focusing on individuals and interactions over processes and tools projects are run by people products are developed by people for

people to use and our interactions either make or break a project and that's why agile is so powerful how did you go let's go into the second second question the executive management in your organization has assembled a new team and dictated that they will use agile for their product development okay that does happen more often than you would expect as well they were they're going to dictate that we're using agile everyone must do this as the project progresses there is confusion about product scope and the definition of what done looks like okay as an agile

project manager what will you recommend to the executive team well this is so great because you know you will come across this in your project management career and in your agile career as well so what are we going to do select a person from each part of the organization to assist to ensure diversity you know diversity is important but potentially this is not the answer in this particular scenario if we have everyone from across the organization they may not even be interested in what we're doing so you know let's not say that one for now

we might have the functional manager select their friends or their favorite team members now that happens a lot as well as you probably might experience or have experienced before but this particular approach is not the best approach in this scenario you know their friends may not actually be the best person for the job you know and that will happen from time to time uh we could encourage a self-organizing team to form including the people who asked for the requirements in the first place and the outcomes oh now these people are going to be super invested

in this product they're really going to understand what they want and what they need out of this project so this is going to be a really good one i think this is probably going to be a good one to go with or lastly we could hire external consultants to run the project and create the product okay this happens a lot as well in an organization so you will see this happen a lot in your career but what happens when you hire someone externally they don't usually understand the business that you're working in or that they're

working in even so they're going to have a lot of lead time to get up to speed in what's happening probably not the best scenario for this one let's go with letter c answer c agile encourages self-organizing teams composed of the people who created the requirements and had the desired outcome in the first place this gives a higher level of ownership of course and product expertise as well and you can't buy this sort of thing so this is why it's so valuable and this is why agile works as well how did you go let's go

into question three you're running an agile project and you meet with the team for the next sprint planning meeting fantastic what will you do next okay great a great scenario based question uh what will we do will we negotiate the scope and costs of the project with the project sponsor uh i mean definitely not i mean project scope and costs this happens before the agile team forms usually and so once you've you've got an idea of the scope which may change of course but the costs are usually fixed so we've got a fixed cost and

then we just we keep rolling out features and keep rolling out features until we either run out of money or you know run out of time and so that's probably it's probably not going to be the letter a let's check out letter b walk through the three questions with the team what did i do yesterday what will i do today and is there anything blocking me what's this describing this is describing the stand up the daily stand up so it's you know it's probably not the stand up that we're going to do at a sprint

planning meeting let's check out letter c the dev team and the development team demonstrates the working feature to the product owner who marks it as complete that's a demonstration or review so a sprint review happens at the end of the sprint uh so i don't know i think we're planning for the next sprint planning meeting um look i don't think we're going to be doing the the the review the product review at this point so let's check out the last one the product owner shares the updated backlog okay this looks promising and the team discusses

it to ensure a shared understanding okay look this letter d probably looks the most promising to me because the product owner needs to come with the the features that they want uh developed in their prioritized order and then the development team or the entire team can discuss it to make sure that everyone understands and that way we know what we're potentially going to be developing over the next sprint or the next two weeks so let's go with letter d for now answer d that's fantastic the product owner should share the updated backlog items and ensure

that entire team has a really good understanding of how to move forward and what we will be working on over this sprint so this is wonderful wonderful way to do it shared understanding visibility of everything involved how did you go let's go into question four question four you're a project manager working on an agile project and you want your team to maximize the value they bring to the customer what can you eliminate in order to maximize project value okay this is going to be great could we eliminate daily stand-ups no not an agile team because

we want that visibility and we want everyone to be on the same page could we eliminate unnecessary features uh probably yes and you know we're always reviewing that so we've got our backlog of work and our list of features we always want to be reviewing this we want this one maybe we don't want this one don't want this one or maybe they can wait until later and maybe we still want this one so we're continually prioritizing that feature backlog so yes i reckon letter b sprint reviews we really want to keep as an agile team

and testing we really do want to keep testing we want to make sure that we're releasing quality items that's very very important let's go with answer b answer b how did you go in addition to eliminating the introduction of unnecessary features oh boy and that is a big one in an agile team i mean in an agile team sometimes you'll get people saying oh just work on this one it won't take you very long yeah but while you're working on this extra feature it's taking you away from your goal and you need to make sure

you have a really really clear goal and you're working towards that goal as the agile team and that's the role of the product owner very very important value can be maximized by eliminating partially done work can be eliminating delays extra processes and features task switching so context switching amazing loss there if that happens any waiting all of this is waste that you'll see in normal project teams that we want to reduce as an agile team we're getting rid of waiting moving information or a deliverable and defects or rework that's a really big one and handoffs

as well because every time we're handing something off that new person has to get up to speed on that item and that takes time and that is a waste so the answer is b excellent how did you go let's jump into the next question you're working on a project and the team have recently moved to an agile way of work okay you'll see this happen a lot this will happen to you in your career one of the team members is confused about scrum and what typically happens after the sprint review okay this is the demonstration

basically the demonstration of the product or the working feature at the end of the sprint so what will you tell them happens next okay hold a sprint retrospective with the team uh that could happen yes so you might have the demo at the end of the sprint and then you might have the retrospective so that's a you know that could happen you might perform a backlog refinement with the product owner no that usually happens before the iteration planning before the sprint you might perform a story card elaboration with the three amigos the business or product

owner the development developers and testers uh again that happens before iteration planning uh when we're elaborating on all of the cards and the story cards that we need to put into the sprint and holding a daily scrum well that happens every day so i look it's you know it's a good one to have but it's probably not going to be that one probably not going to be that one and probably not going to be this one i think the best case scenario is to hold a retrospective at the end of our sprint once the sprint

review is done let's check it out and see a sprint retrospective is held with the whole team after the sprint review but before the next sprint planning meeting we use it to gather lessons learned and look for opportunities for improvement and everyone has a voice for feedback to improve uh things before the next sprint because we're improving the process and incrementally getting better this is really really great okay how did you go next question question six you're working in an agile team and preparing the agile team charter this is our way of work our agreement

our team agreement this is great you work with the agile team to ensure the team charter answers these four questions why are we doing this project who benefits from the project and then the next two let's have a look uh when will the project end some people might be asking that to themselves but we're probably not going to put that in the team charter necessarily and what do we do with the product i mean not really in the team charter what does done mean for the project potentially and how are we going to work together

that's also a good one because this is our team agreement how are we going to have meetings you know what what what is okay within the team and what's not okay within the team this is a really wonderful thing and how much okay let's look at the next two how much risk is on the project uh you know this will come up and it is an important question but it's not going to go in the team charter what's the project scope same deal there them or your classic project management questions that will go in your

project management plan or your pmp how many defects are allowed in the pro product how many defects are that well look quality is everyone's responsibility ideally we have zero defects obviously but you know this is something that we're continually working on in a development team and in any project management team and how many testers are there again look these things don't go into the team charter so i think it's going to be answer b let's have a look fantastic answer b the agile team charter typically covers why we're doing the project who benefits what does

done look like and how are we going to work together and that's from the agile practice guide that wonderful practice guide from the project management institute of the pmi how did you go let's go into question seven you're working with a new agile project manager and explain that agile favors value based measurements instead of predictive based measurements on a project so yeah we're not trying to predict things into the future but we are trying to see how our velocity is going how much work is getting done and you know reducing waste at the same time

so what is an example of value-based measurements let's have a look earned value management now that's definitely uh from waterfall so that's from your classic uh classic project management body of knowledge you'll find that a lot and the schedule performance index same thing for that so variance analysis and estimate to complete again big ones there in the pmbok guide you will find probably not an agile way of work feature burn down chart the features delivered and customer satisfaction this is definitely value so we're probably going to be measuring these and these are actual things that

we have delivered and that we are doing and are improving so it's probably going to be c let's have a look at d variance at completion and cost performance index again big things in the project management body of knowledge and in traditional waterfall methodologies but probably not in our agile project let's go with answer c answer c agile works with value delivered as its primary measurement all the other options are predictive measurements from a traditional project management methodology how did you go i hope you're doing great we're getting through them i mean isn't this wonderful

and how's your knowledge of agile going i hope it's i hope it's pretty good this is a great way to learn as well let's look at question eight agile unified process oh this is great so these are some knowledge based questions it's a it's an auxiliary agile method and it's uh it focuses on performing more iterative cycles across seven key disciplines and some of these uh disciplines some of these processes uh or methods are where agile was actually formed you know it was a combination of all of these different things and aup was one of

those things so we're incorporating the associated feedback before formal delivery but what's not one of the seven key disciplines within a release for agile unified process and if you get one of these questions about one of these auxiliary methods then just think back to the the standard agile practices and processes and then things and methods that you that you will use in a normal agile project and usually it will match up with some of those so let's have a look so we want the discipline of the high level model okay yeah i mean that's a

potential one with feature driven development we develop a model first and then we deliver parts of that model until it's all complete and then we do it all again discipline in managing stakeholders expectations look i mean that's important in any project but it's probably not one of the things that we'd call out in an agile project we always want to be communicating with the with the stakeholders instead of managing their expectations really so it's probably not going to be that one i think i reckon that could be our answer of what is not one of

these disciplines discipline in testing testing is really important especially in an agile project discipline in configuration management configuration management is where we're usually where we're uploading a part of the code every day so that we can and we're testing it so that we can see if it's worked and merging all of these things together to see if it's broken anything so what's not one of these disciplines is probably going to be answer b answer b agile focuses on transparency to ensure the customer needs are met not in specifically managing customer expectations and again that's from

the agile practice guide a wonderful book i really really recommend that you check that out how did you go let's look at question nine you're leading a coaching session with your project team on the additional agile and lean frameworks that have contributed to the agile way of work fantastic what frameworks will you share with the team so agile and lean frameworks let's have a look project management plan and project charter not agile and lean framework scaled agile framework large scale scrum these are additional agile and lean frameworks yes they are and potentially these are scaling

methodologies where we're now using them across teams and we've got multiple people and and then you you might have across teams again so we're looking at programs and portfolios instead of just projects themselves potentially answer b working group meetings post-mortem project meetings probably not that one normal projects flow charting and affinity diagrams flow charting and affinity diagrams you may use these with quality and lean methodologies but they're not specifically lean methodologies they're more you know a business analyst might use these to extract information but i'm probably going to say it's not that let's go with

answer b for now that's great answer b agile and lean frameworks include scaled agile framework so safe it's a safe framework large-scale scrum or less scrum of scrums sos dynamic systems development method dsdm along with more common kanban extreme programming or xp and scrum and that's fantastic that's from the agile practice guide let's look at question 10 i hope you're going well we're really getting through them and you're doing great last one introduced by alexander cobon in his book crystal clear and created ibm in 1991. look at that i mean how many years or 30

years ago so that's how how much history there is with agile now you know it was created in 1991 part of this methodology it's a framework for focusing on individuals and their interactions which is one of our key agile you know things that we go through that you learn at the first part of agile now it's opposed to processes and tools it's the first agile principle as we know it is not a set process but it's a guideline for the team to collaborate and for them to communicate so which is not one of the core

beliefs of crystal let's have a look okay technologies change techniques okay that's potentially one that we want to keep because the technologies that we use we may need to change the techniques that we're using depending on the technology that we're using if we're all in the same place we might be able to have daily standups in the same room if we're if we have access to video conferencing or you know other messaging tools online especially during a pandemic for example then you know we might change the techniques that we're going to do as a team

let's keep that people change functions oh gosh i'm not sure about that one cultures change norms so the culture in an organization will change the norms that we have that you know the normal things that we do so we're probably going to keep that and distances change communication of course if you're co-located much easier to look over your shoulder and say hey billy you know have you got that information that i need and billy can say yes i sure do and it's right there but if we're you know we've got teams in shanghai teams in

new zealand teams in england then it's going to be very different communication so and that's part of the important part that alexander coburn was calling out as part of his methodology so i think the one that does not match here is people change functions let's go with answer b answer b crystal clear describes the three core beliefs as technologies changing techniques cultures changing norms and distances changing communication all reasons behind the core practices of agile such as stand-ups collaborative user story creation retrospectives and the whole team approach and that is ten wonderful questions into agile

how's your knowledge uh did you learn anything did you already know everything i will either way i hope it's been a whole bunch of fun and i've really enjoyed spending this time with you as well you're working on a project in the role of scrum master and have set a meeting with the team and the product owner to refine the product backlog what should the team do in this meeting so are refining the product backlog meeting or backlog grooming so should we estimate and refine the work items we're grooming them and we're refining them that's

a very possible one i like that one should we prioritize the work items no the product owner should do that before they come to this meeting and they should always have a prioritized list should we add features to the product backlog uh no definitely not uh that should probably be done you know before prioritizing them and before we get to this meeting as well and should we identify fixes uh in this meeting no definitely not uh identifying fixes you know that might come at any time maybe there's issues or maybe there's defects we might also

build slack into into our sprint out of all of these we're probably going to go with answer a answer a the product owner adjusts the priority of the product backlog items the team is responsible for estimating and refining those work items so now we need to estimate as a team and figure out how much we can complete during a sprint each time the team refines their estimates with a higher level of details so usually we'll just revisit them we'll start off with a very high level estimate and we'll get get a little bit more refined

every single time how did you go let's go on to the next question you're working with a team who would like to become agile the functional manager asks you what the difference between kanban and scrum is what will you tell them so kanban teams plan their work in sprints or iterations no that's probably more scrum there are no work in work in progress limits in kanban work in progress limits is what kanban is all about so it's probably not that one either kanban teams work on a project as a whole possibly not because we work

on increments really not a product as a whole and kanban teams employ a pool system now that is exactly it because we've got a kanban board and we start and the work is pulled across only when the team is ready to work on it and that is the beauty of of kanban it limits the work in progress because we're only pulling what we can work on let's go with answer d answer d the main difference between scrum and kanban is that kanban and teams employ a pool system this means that an if an item of

work is completed it triggers someone to pull the next item into the queue onto the board to work on and kanban teams work off a kanban board that displays each task and it has a limit to how much work in progress can be in place a wonderful way to work how did you go let's go on to the next question you're working on a new project with an agile product development team who have self-formed and chosen a scrum master called jeremy jeremy immediately sets a meeting with the team to explain and flesh out their team

charter what has made jeremy a good choice for scrum master okay team charter is a wonderful place to start it sets the benchmark for how we're going to interact as a team it's an agreement in a way okay so he likes to work within set processes that's typically not an agile method we're more about the interactions than the processes and tools he has been with the company for more than five years that might make him good at his job but possibly not for a good scrum master he shows servant leadership and engages the team in

team decisions now that is what we're after we're the scrum master we want servant leadership we coach the team and we remove blockers and we engage the team in decisions we're not dictating to the team so it's probably going to be c here lastly he sticks to the plan and he does not change probably not an agile method here as well we want to respond to change as an agile team so let's go with answer c jeremy shows the traits of servant leadership by engaging the team in team decisions starting with the team charter and

ground rules so that everyone knows where they stand this is really good practice a really good way to do it by communicating the reasons for his decisions he's a suitable scrum master and will be less focused on command and control or dictatorship we want the team to be involved that increases engagement and that increases the output of the team how did you go let's go into the next question you're managing a project as an agile project manager and a business representative for the product you're delivering asks you how many defects were found in the latest

round of testing well this is a great question now you don't know the answer off the top of your head and that is totally okay because we're working in agile what should you do you should you guess the number of defects and then change the subject this might happen quite a lot actually where you work but this is not the agile way we have a better way to do this let's find out um should we tell the business partner you will send an email to him with the information uh probably not because we really want

to be face to face and interacting as a team that's more of an agile methodology so probably not that one either should we take him to the team area where the information radiator with the project information is displayed and that should show us the amount of defects maybe the velocity of the team the amount that's been completed in the last sprint but this probably is going to be one of the best best answers here so answer c we're going to give that a take or lastly should we ask the business partner to call the scrum

master to get the correct answer not necessarily because we want the information to be available to everyone and that's part of the deal with the information radiator it's information in a in a common place in a co-located place that anyone can see at any time very very valuable they can self-serve in a way so answer c a core component of agile is visual management and transparency part of this are the various parts of the project information radiator now it can be physical in a physical place but it can also be you know on a confluence

page or on a web page for example this includes things such as the team velocity kanban board product backlog the burn down chart and the latest test results and issues and the results of retrospectives all great information to share with anyone who wants to know about what our team is delivering how did you go on to the next question you're working in a company that is moving from a waterfall methodology to agile you mentioned to the business unit manager that the team will be better prepared to respond to change and meet customer needs using agile

okay why is this the agile team works directly with a business owner or representative to constantly prioritize delivered value ah i mean i love that one that's probably going to be the answer i love that answer because we're constantly reshuffling and making sure that we're delivering business value according to what the product owner or the business or the customer wants that's a great answer okay next one the agile team delivers the product all in one go no that's not what agile is about we deliver in increments and small pieces and features the agile team is

for developers only so development will improve also not true agile can be used by anyone because we're delivering business value and we're wanting to deliver features those features don't have to be technical it's just a way of work the business partners review statuses and ask for recommendations not usually the business partner will give us the idea of what they want to be worked on so the features and the business value that they want delivered so they usually tell us what they want delivered so let's go with answer a here and answer a that's great working

with the business partners or someone who represents the customer almost daily is a part is a key part of agile the team hears what the business would like the results to be and meeting face to face is better than reading requirements like emails or documents or even a conference call so we really want to meet where possible and get together face to face and that way we can get a lot more information about what's going on this is a great oh this one's a long one and they're all going to be scenario based as well

which is really really fantastic exactly like they will be on the pmp exam for agile life cycles two kinds of planning occur release planning and iteration planning in release planning business representatives such as the product owner establish and prioritize the user stories for release so that's our product backlog in collaboration with the team refining larger user stories into a collection of smaller user stories okay this is great so far what is the incorrect description below regarding iteration planning and backlog preparation wow okay this is a real mouthful this question but you will come across questions

like this in the exam as well so let's see what we've got the backlog is the ordered list of all of the work presented in story form for a team that seems pretty good the coach encourages the team to work alone so no no one bothers them okay probably not this one sort of against agile principles we really want to work continuously as a team collaborating all the time like around each other so it's probably going to be that one the facilitator encourages the team to work in the triads of developer tester and product owner

or business analyst so this is the the three amigos that you'll hear about and that's definitely one of the agile core practices and the triad discuss write and then place enough stories into an iteration and enough features for a first release that's also a wonderful practice in practice when you're actually doing agile so i think we're going to go with the incorrect answer being b answer b answers a c and d are correct in describing backlog preparation for iteration planning according to the agile practice guide from the agile alliance and project management institute a wonderful

wonderful guide if you ever get into it how did you go let's get into the next question behaviour driven development or bdd allows a developer to focus on testing the code based on the expected behavior of the software and is a method of writing user stories okay and acceptance criteria basically so acs this is a really really great way to do your user stories uh if you ever get into it what is the correct description regarding behavior driven development acceptance based criteria well that's also a bit of a mouthful uh so what have we got

here make buy and do uh i'm not sure about that one i haven't really heard of that tell show and repeat okay i'm not sure about that one either find create and perform are these fantastic these could be models in their own right you know and so don't get tripped up by these sorts of things given when then that oh and i didn't mean to cross that out but given when then given something happens given a certain circumstance when something happens then i want this to happen that is our behavior-driven development for acceptance criteria let's

go with answer d answer d given when then is the way a behavior driven development is used particularly when outlining user story cards for iteration it highlights given a certain situation when something happens then we want this to happen every project has characteristics around requirements delivery change and goals understanding the different types of life cycle you can choose the right one for your for the circumstances of your project so different project life cycles we're talking about here what is the correct description for a waterfall approach and you know we need to know this because while

a company may or out even our team may say that we're doing agile sometimes we're actually doing a combination or a little bit of waterfall and a little bit of agile so let's check this out a waterfall approach is predictive yes definitely predictive but they all say predictive so that's going to trip us up okay we've got fixed requirements yes that's definitely true so these ones are fixed requirements so not variable and not variable that's more of an agile methodology there fixed requirements performed once for the entire project that's also true and it's in a

single big bang delivery so all at once we do all of our project and then we release at the end whereas in agile we're continually releasing features uh and basically continually delivering delivering value in smaller releases so it's probably going to be answer a for this for a waterfall approach answer a a predictive or waterfall project management life cycle focuses on fixed requirements performed once for the project in a single delivery every project has characteristics around requirements delivery change and goals understanding the different types of life cycle okay we've got another lifecycle question fantastic now

we can check out the other types so we want to choose the right one for the circumstances of our project and this is really helpful because if we do have a high change environment then maybe we do want to select an agile life cycle or if we have a low change environment with low risk then maybe we can just do one big bang project you know like a waterfall approach so what's the correct description for an iterative project approach and this is important because agile is made up of iterative and incremental and those two things

form the agile approach basically so let's figure this out iterative is dynamic requirements uh iterative repeated until correct in multiple deliveries okay with iterative what we're doing is we're iterating towards success so we're continually changing so i think we're probably not going to have fixed requirements so we could probably get rid of these and so dynamic requirements because we're iterating we're continually improving so dynamic requirements but it's not multiple deliveries it's a single delivery only and we're continually improving until we get to that final uh that final release basically and so let's go with answer

b dynamic requirements they're repeated until they're correct so continually improving but they're done in a single delivery so let's check it out answer b okay thank goodness that one was a bit tricky iterative methods have a have dynamic requirements so they're ever changing but they're ever improving and they're repeated with that feedback until they are correct but they're delivered only once so so once for that for that increment but once overall and if we're doing increments then we're delivering increments and that's a separate story maybe that will come up soon let's check it out not

in the next question unfortunately the team charter is also a social contract okay we're taking a little bit of a different track here which of the below is not usually a part of an agile team charter team values such as okay that's definitely a part of a team charter sustainable pace really important and core hours of the team working agreements such as what ready means and what done means really important as well good to go in your team charter ground rules such as one person talking in a meeting also really important and schedule performance index

and cost performance index for the project these are more terms from the project management body of knowledge probably for a waterfall approach all done in one big bang where we're predicting the elements around our project so i think not for a team charter is answer d answer d the agile team charter focuses on the vision the why and the team's way of work the spi and cpi cost performance index earned value management metrics from a predictive project methodology so your waterfall approach and they're not part of your traditional agile team charter let's get into the

next question you're working with a team that is new to agile and you're using scrum to manage the project the business representative is confused about the difference between a sprint review and a sprint retrospective what will you tell them okay let's check it out the sprint reviews demonstrate the work completed in the sprint yeah that seems promising sprint retrospectives look at all the work completed in the project okay that's not right for that second one sprint reviews discuss what is worked on in the sprint uh that seems right as well sprint retrospectives are done at

the end of the project for a lesson learned opportunity i mean you can do that but we want retrospectives done at every iteration at the end of every iteration so probably not that one either sprint reviews uh review the lessons learned sprint retrospectives look at the history of the product retrospectively no definitely not that's just um a little bit i don't know what that means actually i mean it's definitely not that and lastly sprint reviews are for product demonstrations yes that's it we're demonstrating the product to the business or the customer and sprint retrospectives are

for lessons learned i mean yes that is true as well but ideally and it didn't mention it here we're doing it at the end of each iteration so we can iterate and continuously improve our process so i think the best one is going to be answer d let's check it out answer d sprint reviews are for product demonstrations sprint retrospectives are for lessons learned where we ask what went well what didn't go well and what did i learn keep going you're doing great let's check out the next question you're working on an agile project as

a team member and begin gathering the product requirements what is the overall first question that you should ask and use as a guide for your work okay let's check it out how long will the project last uh some people might ask be asking that but i don't think that's really what we want to i mean it is still valid but probably not for an agile project well let me let's see what else we've got what is the business value okay definitely definitely business value definitely business value that's the core driving force behind what we're delivering

in an agile team uh how much is the budget you know again these are valid questions but probably not the first question that we're going to be asking and how many team members are there that will participate you know again all of these questions are valid in a project we do need to know these things but the the core question is what is the value that we're delivering what is our core purpose so let's go with answer b answer b agile projects center around delivering business value and working closely with the customers and business representatives

to ensure that the value is always correct so we're changing if we need to business risk and the impact of not undertaking the project must also be considered yep very true we're really getting through these questions you're doing great so let's see what we've got next the agile team for which you're the project manager has determined several key features to deliver to the customer how should these tasks be tackled by the team okay key features that's what we're after the features should be prioritized tested and delivered incrementally probably yes that seems like a good one

the features should be delivered quickly whether or not they're complete to gather feedback oh no i mean we still really want them to be complete people think agile is about being fast and it is about being fast but it's also about quality quality is really important so we're delivering a whole feature that's complete and usable and obviously good quality probably not number b oh let it be the features should be delivered according to the project plan uh i mean in a way but project plan sort of is more of a waterfall approach where we're planning

everything out all in one go and all the features should be delivered at the end of the project again more of a waterfall approach so let's go with answer a and see what we've got answer a agile is a combination of incremental delivery and iterative development so we're delivering in small increments and we're continuously improving as well over time and getting that feedback that means business value is continuously and iteratively improved and prioritized so we change if we need to and it also means it's delivered in increments that the customer can see feel and touch

and use and these features should be complete tested and quality is everyone's responsibility yes we have testers but we do have quality it has to be built into the requirements built into the features the solution has to have quality you know built in around it and so that's a really big part of the whole team approach in an agile team all right we're doing great we're really getting through these questions keep going what's our next one look like you're working on an agile project and the project team have just finished an iteration fantastic the all

tasks for the iteration have been completed and you're ready to move on to the next iteration but you're not sure what the team should work on okay what will you do next and these are great scenario-based questions aren't they so you will see this sort of question on the pmp exam around agile in a scenario so what will we do we follow the project plan developed early in the project probably not because that's more of a waterfall approach will we follow the project management office who's already determined how the project should progress again probably not

more of a waterfall approach should we ask the product owner who continuously prioritizes the backlog that looks very promising so we've got our backlog of items or features and sometimes one might move up one might move up this one might move down but it's all prioritized by the business who's represented by the product owner probably answer c uh let's check out entity the ask the project coach or team leader to determine the next iteration uh no yeah okay so so team leader it's a team approach and so part of that team is the product owner

prioritizing those features let's go with answer c answer c the product owner represents the customer who you're delivering that business value to the team works through the list of items that have identifiable value and have been prioritized by the customer that is wonderful all right let's see what we've got next there's only a couple to go you're doing great while meeting with the customers or business owners they introduce several pieces of new functionality into the product backlog list oh and this can happen all the time the deadline for the product cannot be changed okay this

is a great scenario let's see what we're going to do what will we do next should we tell the team to work overtime in order to deliver the project and look many projects will take this approach they'll say okay we're going to throw resources at this we're going to hire extra people okay everyone all hands on deck but you know what in agile that's not the approach we're going to take because we're about a sustainable pace we want it to be sustainable forever so let's see what else we got stand by your team and tell

the customers the project will not be delivered on time okay now here's the thing agile's not about that either because we're wanting to continuously deliver value and features and pieces of increments that customers can see feel and touch so we still want to be delivering value it's probably not that one should we be sure the customers understand that lower priority features may drop off the project completely now that looks promising we can still deliver things but we'll deliver the high value features and the lower value features will potentially simply drop off or maybe be finished

at the end of the project if there's extra time left that looks very promising that one lastly agree with the customers to have all new items put into a separate category that will be completed if time allows look i mean that's also a decent idea but i think with agile we're looking at prioritization so prioritization the prioritization of business value which is hard for me to say but easy for us to do because it's the right thing to do let's go with answer c answer c an agile project can accept changes even late in development

and that's one of the agile principles isn't it so while the competing constraints of cost quality and schedule are often fixed in agile the scope can vary over time and this means some features may need to drop off and others become prioritized above them a maintainable pace is required as well so project managers must not overwork the team because what happens then the team gets burnt out and then people quit or leave or stop working you know or hard as hard or get disengaged in their work and so then the pro product quality drops off

so having a sustainable pace is also extremely important and it's a part of this answer so that's really really good and so we must not overwork the project team to increase the project pace of work so really really good at a really key lesson in agile we're doing fantastic let's check out the next question guys every project has characteristics around requirements oh good it's another project lifecycle question fantastic delivery change and goals understanding the different types of life cycle will allow you to choose the right one for the circumstances of your project what is the

correct description for an incremental project management approach and this one's a lot easier for me than that iterative one because we're delivering in increments it's right there in the name let's see what we've got so fixed requirements activities performed once in multiple deliveries uh i mean potentially except we want dynamic requirements i think so we're it's we're heading towards more of an agile approach here so let's go with we've got b b and c as dynamic requirements activity is repeated until correct uh in one large delivery okay definitely not one large delivery so we want

multiple deliveries here so dynamic requirements performed once for a given increment okay that seems fair infrequent smaller deliveries yes that's also fair so for each of these increments we're actually going through the whole process and then delivering and then if we're iteratively iteratively improving then you know that's a separate thing but for each one we can iterate as well and when we combine those two things together we have our agile approach so let's go with answer c answer c incremental project management approach includes dynamic requirements performed once for one of those increments and those increments

delivered in smaller frequent smaller deliveries that is a wonderful way and i think we've learned a lot about agile just going through these questions so far you guys are doing absolutely fantastically and i think you're doing a great job for going through these and i really really think that you're going to prepare well for your pmp exam or any other agile certification that you might be going towards as well there are certain core practices that are among uh that are common amongst various agile frameworks okay so there are lots of different agile frameworks or that

have sort of been created or that even where agile came from as well and so but there are common practices between all of these different frameworks so they're used within any team that calls themselves agile which of the below is not a core agile practice and this is good because you'll see different variations of this in the teams that you work in you know just depending on the circumstances of the organization every organization is different so let's have a look team iteration planning okay i like that one we definitely need that collaborative user story creation

between the business customer developers and testers yes i like that too we definitely need that demonstrations and reviews of the features we want to be demonstrating and reviewing the uh the features that we're delivering and autocratic leadership to ensure the work gets done i think that's more of a top-down leadership style which is definitely not really the way agile works it's more bottom-up and the team working together around a core thing that they really believe in so i think what is not a core agile practice is answer d let's have a look answer d the

preferred style of legion leadership in an agile team is servant leadership autocratic leadership typically is a one-person affair while servant leadership builds psychological safety because we're serving the team and growing the team and it's for the whole team to engage and contribute all other items listed are called core agile practices so that's wonderful all right let's check out the next question poor specifications are often a major reason for project failure okay that's so true in agile development user stories are written with the developers testers and business representatives with frequent frequent reviews yes even though that's

hard to say that's a really good thing to have and we're ensuring that they are right so which of the following is not correct regarding collaborative user story creation now while that was a bit of a mouthful let's have a look this is really clear and it's great to see that collaboration in an agile team that's what keeps these requirements correct and maybe we need to adjust them over time so let's see we've got a user story addresses both functional and non-functional requirements uh okay i think that's probably true i definitely like that one we

do need that in a user story the project sponsor must sign off on all user stories in advance probably not that's you know probably more of a waterfall approach you know if any approach at all so it's probably not going to be that one let's have a look our user story includes acceptance criteria for the feature yes we want that and characteristics for acceptance criteria must be estimable small and testable yes absolutely true these are really good ways to do your user stories so the correct incorrect answer i think is going to be answer b

answer b while it is common for the developers testers and business representative to agree on the story card criteria it is not signed off by the project sponsor directly the product owner representing the business or the customer grooms that feature backlog so that list of items and they uh basically by doing that we're always ensuring that the highest value items are going to be delivered according to what the product owner has said really important so that's a great way to do it how did you go all right let's check out the next question in continuous

integration configuration management compilation software build deployment and testing are wrapped into a single automated repeatable process wow and you know this is a really mature team that can can get this up and running and where we're we're able to deliver something very quickly if we need to because it's already been uh put up into the one build and we've tested it automatically to see if anything is broken so defects in the code here when we're doing continuous integration are not an issue making it an ideal method no they're definitely still an issue we still need

to look out for defects and make sure that they're that they're not happening they're detected more quickly because they constantly integrate their work build and test yes that's one of the benefits of continuous integration because we're checking out if the whole build works together and if anything is broken if there are any defects there so it's probably going to be that one defects are integrated into their work as part of test driven development ah no that usually happens while we're you know before so we do the test first then we develop the code and then

then we test it again to see if that test has passed so all of that happens before the continuous integration or merging the code so probably not enter c and answer d collected and fixed in an iteration at the end of the project to avoid delay no we really want to fix them as we go ideally and we don't we you know quality is very important so we want these these defects to be fixed as we go ideally and found quickly as well so let's go with answer b continuous integration merges code to a test

environment using an automated process including automated regression tests to ensure nothing is broken so just null tests of the everyday functions of of the feature that we're working with to make sure that it's still all good and test driven development so this allows the team to find and fix defects more quickly which is what we want and test driven development writes a test first which fails at first and then we write the code to ensure that the test then passes so that's a separate thing but that's test driven development that was a great one well

really good and a little bit technical how did you go let's check out the next question so agile has certain core practices that are used within any team in an agile way that are using in an agile way so which of the following is not a core practice of agile okay this is great we've got another one of these and this is really really cool so we've got the whole team approach where any person is needed who is needed is brought into our project team yes that's part of an agile approach we want any external

dependencies brought into the team so we can collaborate with them ideally you know sometimes it's not always possible but that's how we want it if we can get away with it then we've got early and frequent feedback again that's an agile approach so we want a common understanding of the product we want everyone to be collaborating on a regular basis daily stand-ups to report progress and raise blockers also an agile approach so it must probably gonna be d reporting to executives to ensure they're happy with your project okay this is not really a direct agile

uh you know core practice so it's probably going to be answer d but you know reporting to executives is done in a different way usually we just make all of the information that we have in our team available so we can see the burn down charts you know we can see the product backlog we can see what's going to be delivered and all that is simply made visible to anyone who wants to walk through the team area or you know in a soft environment or a online environment we might have a web page or you

know a confluence page or something similar and that's how we do it there so anyway let's go with answer d that's great while reporting to executives has its place when running a project in agile it would rather be done by including them in other core practices such as demonstrations or reviews oh that's a good one too so we're demonstrating the product at the end of the iteration or we might show the product burn down chart or the backlog of work so those ones i did get which is great and all of the other items in

our list here are agile core practices oh that was another really good question all right let's see what we've got next you're working on a project on agile project as an agile project manager you look at the product backlog and ensure that several features or minimum viable products mvps can be scheduled for delivery throughout the duration of the project why is that a good idea okay this is great and again really agile approach because we're delivering features on a regular basis and that's what we want so do we want to show executives that progress is

being made by the development team i mean kind of but that's not the core reason to keep the project duration short no project could go on for a while we might just be delivering multiple features to enable users to test the product for quality and give feedback i mean for an mvp yes possibly and to enable the business to get value quickly as the features are delivered oh it's probably going to be answered d because that's the core reason of agile is to deliver business value and to do it quickly so i'm going to go

with answer d let's have a look oh thank goodness minimal minimal minimum viable products usable features in their own right and they're delivered incrementally so that's what we're after we're delivering features on a regular basis this allows for business value to be gained more quickly because ultimately we're delivering these these core bits of value which is really good and we're also gathering feedback on these as we're going are they having the results that we wanted and maybe we need to mix it up or change or reprioritize those features with the product owner now we're really

starting to get into the agile way of work this is really great let's check out the next question you're working in a comp on a complex software project but you see that the team uses a whiteboard and writes tasks on cards or sticky notes the business representative seems put off by the use of these low-tech tools on such a high-profile technology project what will you tell them oh and this is so great because with agile we don't necessarily need high-tech or fancy tools it's about the individuals and the interactions and how we facilitate that and

that's much more important so this is going to be great so the team are using low-tech tools so that low-tech people can understand them okay probably not that one i mean that's not the core reason although it does have its benefits you know sometimes it's less confusing to use low-tech tools and even i enjoy that so a whiteboard is actually a complex thing they just don't know it yet okay uh we'll do some reverse psychology there on on the on the business sponsor probably not that one as well uh the team is using the principle

of visual management oh yes this looks good and by using a physical board it is transparent to anyone who needs that information so visual management we're making it transparent and visual to anyone who needs it that's what we want uh probably going to be answer c the team will drop everything and develop a new software-based kanban board to avoid embarrassment oh yes now while you may see this happen in your career uh you know in in regards to executives or or you know these sorts of things happening in your projects definitely can happen uh we

still would prefer the individuals and interactions let's go with answer c visual management is a lean principle borrowed into agile so way back when in the toyota production system back in the 1800s even you know into the 1900s borrowed into agile and now used really effectively which is wonderful and it's where we make key pieces of information as accessible as possible often found in the team area and often physical but it doesn't have to be it means anyone can walk through that area and see what they need at a glance kanban a kanban board is

also an example of a low tech high touch tool that's great so that was a really wonderful question and a good experience let's see what we've got next agile teams practice frequent verification and validation during and at the end of each iteration through demonstrations and reviews beautiful a great agile core practice which of the following is not a benefit of demos and reviews okay let's see what we've got here it enables the team to catch mistakes and mismatched customer expectations early i think that's a good thing it keeps everyone busy and gives them something to

do oh i don't think that's really the core reason for a demonstration and review uh it actually has a really special reason and it's you know helping to deliver that value and make sure that everything's correct so let's see what else we've got it's easy to manage since there are multiple feedback loops that's possibly that's really probably true really because we're getting everyone involved to give that feedback it reduces cost overruns as mistakes are found early prior to additional tasks being built on a faulty foundation yes absolutely true i think in this case the correct

incorrect one is going to be answer b answer b busy work does not add value to the project and it's not a benefit of agile i couldn't have said it better myself so that was a nice easy one i really liked that question all right let's see what we've got next you're on an agile project or agile software implementation project with a very short deadline okay now this happens quite a lot as well how do agile teams shorten the time between identifying a defect and resolving that defect oh this is good continuous integration uh yes

probably that one because we're we're putting the all of the code or merging all the code into into a core test build basically to see if there are any defects coming out of that maybe we do an automatic regression test uh just to see if anything is broken and if it is then we can identify that defect really quickly so i think we're probably going to go with answer a here daily build and smoke tests i don't think the smoke tests as part of it usability testing also important exploration test testing all of these things

are important but as a core agile practice continuous integration i think we're going to go with that because it automates that whole build and sees and checks if everything works as a whole answer a that's good continuous integration aims to merge the code and have a working build once a day then executes automated tests quickly to see if anything is broken now this is easier said than done so it's a very advanced practice and yeah i mean it can be hard to to do and to manage and to pull off but it's definitely one of

those things that helps figure out those defects very very quickly if we can get it up and running so this frequent checking ensures less time passes before a problem is identified and that is what we want in an agile project an agile team all right you're doing really really great let's see what we've got next with all the different methods of testing either a software or a product deliverable when should the team determine the acceptance test criteria for the feature or story card okay this is really good so we're wanting to do the acceptance criteria

usually with our business analysts or even with our product owner themselves as well so when the first iteration is complete probably not we want acceptance criteria before that so that we can deliver those features don't we or that iteration during the estimation and elaboration of the card with the product owner business analysts and development team oh yes estimation and elaboration that sounds very promising we're elaborating on the card building out those acceptance criteria of points before the product or feature is prioritized uh no we want it prioritized first and then we work on the ones

that are prioritized to elaborate and estimate on those cards and at the end of the project probably it's going to be too late by the time we get to the end of the project if we even get there if we haven't got any acceptance criteria on our cards so let's go with answer b i think for this one answer b acceptance tests and criteria are given before the development of a deliverable and care and during elaboration often in a given when then so yeah so your behavior-driven development given a certain circumstance when this happens then

i want this to happen or another way is as a you know customer i want this to happen so i can get this done you know that's another way that we can do it with a customer lens and so these are great ways to do your acceptance criteria and obviously we need to do that during the estimation and elaboration of the card doing great guys okay next question let's see what we've got every project has characteristics around requirements delivery change and goals this is another life cycle question hooray oh and it's what about agile oh

well this is what we're here for so let's see what we've got here understanding the different types of life cycle will allow you to choose the right one for the circumstances of your project and this is really important because every project and organization and product and even your country and the culture everywhere you know even the place that you're working in the team that you're working all of these things will affect how your project is delivered and maybe we take a flavor of some of these things so this is really important to know choose the

correct description for an agile approach let's see what we've got agile dynamic requirements okay that's the first one that is correct so we don't want the fixed requirements ones we don't want those so dynamic requirements they're repeated until correct yes both of those are right uh infrequent small deliveries yes that's correct in a large small delivery no so we don't want in a large small large one single large delivery so it's probably going to be answer a here that is what we're after answer a the agile project management approach includes dynamic requirements repeated until correct

with smaller frequent deliveries frequent smaller deliveries and that's that's why we do agile and that's from the agile practice guide a really great book from the project management institute and the agile alliance all right let's check out the next question you guys are doing really really great stick with it you're practicing and this is going to make such a big difference for you so let's i mean this is so great let's see what we've got in the next one and then we'll go from there continuous integration wraps software build deployment and testing into a single

automated repeatable process and this merges all of the changes to the software and it separates each feature into its own development pool i don't think so ensures no code is changed no integrates all changed components regularly at least once a day that's the idea behind continuous integration or enables new features for the product backlog not that one either not that one either so let's see what we've got answer c continuous integration is designed to merge all of those changes made to the software and test them automatically discovering any defects or issues on a daily basis

again quite hard to pull off or to do in practice but once you do get to that stage it's one of the fastest ways to find those defects and a really great uh great way to do uh your testing and and making sure that everything works as a whole all right guys this is the end of this particular section you guys have done absolutely fantastic and i've personally enjoyed spending this time with you crystal is one of the original frameworks that contributed to agile it's designed to scale and it realizes that each project may require

a slightly tailored set of practices based on the size and complexity of the project and of course projects are going to be different you know every project you work on will likely be different even though you know people might think that they're very similar you're going to have different people different experiences you know you're going to have some different approaches you're going to have some different technologies all the time different things are creeping into our projects and so the core values of crystal and uh this is from alastair coburn from the early 90s basically created

this framework and it was an input into agile so we've got the choice of people interaction and community and whenever you get similar questions to this or anything around the existing agile frameworks or the pre-existing agile frameworks just look at what is common with agile today so we know let's go through these well so finding people building people leading people that certainly is promising from an agile point of view um that's a that's a maybe building products buying products and selling products not really to do with agile agile is more about people and interactions isn't

it you know for the agile manifesto profit persistence and power you know while they're certainly they are things you know that's probably not specific to agile in this case around people interactions so uh the first one people interaction and community is probably our best bet because it actually mentions those two things directly so let's go with answer a answer crystal's core values include people interaction and community in the same way as agile is based around iterations over processes and tools and your interactions sorry over processes and tools and understanding the impact that these things have

on the work and getting things done and that's one of the benefits of learning about crystal the impact on the way that you work how that impacts the work that gets done and you'll find that in your career as you work on projects and particular agile projects as well how did you go let's get into the next question of more crystals so this is good crystal is designed to scale and realizes that each project may require a slightly different tailored set of practices based on its size and complexity and that's part of the big thing

about crystal is is it's designed to change depending on the size of the project so what are some of the ways that crystal scales okay this is good crystal blue indigo and violet based on number of features crystal clear yellow or red based on the number of people i know that's one because the number of people will severely impact your project how many communication channels and opportunities there are for people to talk and or miscommunicate even so you have to keep communication really clear and really involved in in a larger project crystal uh metal wood

and water based on the flow of story cards through the kanban board all of these like seem like they could be the right answer um but i think we're going for b at the moment uh crystal high low and medium based on dollars spent on the project and i think with crystal there is a dollar a dollar value that is used to determine how large a project is so it's people it's it's dollars you know it's the risk of the project things like that but crystal clear yellow or red uh are the ones that crystal

actually uses and let's have a look let's go with answer b answer b crystal clear yellow orange and red are based on fact factors such as people involved zero to eight money involved and the general comfort level of the project often involving risk so is it high risk is it a low risk you know that will help us scale and use our scaling methodologies with agile in our scaling frameworks all right they're starting to get a little bit trickier so let's check out the next question you're working through an agile project with your team meeting

daily in a daily stand-up what is not one of the reasons that agile teams use daily stand-ups okay so not one of the reasons to micro commit to the team okay no that's a good reason we like that uh to uncover and remove blockers we definitely want that as well to ensure work flows freely through the team so to remove those blockers to help that flow of work we really want that that's part of agile and that's why we do it and to report to the executive team uh i mean not directly i'd say that's

probably our incorrect answer and the thing with this is you can invite executives to the stand up so that they can come and see what's going on you can invite them to the showcases you can invite them even to your retrospectives if they would if they would be inclined to come along some of the good ones will come along and see how your team is going but usually a stand-up is not directly there just to report to the executive team even though they can be a part of the team because agile is an open approach

so let's go with answer d enter d that's a good one stand-ups are used to micro-commit to each other uncover blockers and ensure the work flows freely through the team while everyone including an executive is welcome to join they're not specifically for reporting to an executive team well that's exactly what we found isn't it so that was good um hopefully we get a similar question like that on the actual exam all right we've got a couple of questions to go you're doing great you're the project manager okay oh this is good probably a scenario based

question similar to your pmp or acp exam uh you're a project manager on an agile project that is halfway through the project sponsor is starting to raise concerns that the project will not be completed in the allotted time and you know what this is happening to me right now in the real world this will happen to you all the time because projects can get messy and whenever there are people involved different people have different agendas and so you know this is life this is a wonderful part of life this is a wonderful part of agile

and having a framework to deal with it and work with it in a positive way it's so powerful so let's see what will we do to gather the information necessary to answer the project sponsor to so to see how the project is actually going and you know they need to know this information because they may need to report back to their superiors as well especially in larger organizations um all right let's have a look so review the kanban board and the current work in progress uh look that's possible so but that might just be for

one iteration maybe so let's have a look check the product backlog for remaining features i mean that's possible as well you know these are okay answers because if we can see the backlog we can see how much there is to go but it won't tell us how long there is to go so answer c review the team velocity the product burn down chart and other key performance indicators so this will give us more of an indicator on on how the team is actually tracking against that work i'm probably going to go with answer c at

the moment have a team meeting and answer and log everyone's status it's definitely not that one okay so at least we can cross one off the list here but if we're trying to figure out the allotted time we might want to use the indicators of how time is proceeding so like a burn down chart and the team velocity let's go with answer c answer c that's great agile key performance indicators include team velocity the rate of progress so that's how much how many story points are we actually completing on average and we don't want to

try and push too much more than that we don't want to over burden the team because we want a steady pace that we can continue indefinitely we don't want to go up and down and rush and slow down because that burns people out and it reduces the morale and the engagement of our team so you know a steady pace is really really important and remaining work so these can be shown visually as well such as on a burn down chart reviewing these kpis will give you the most reliable answer in this case that was a

really good question how did you go i think we're onto our last one for this session you guys are doing great this is the last one let's check it out you're attending a kickoff meeting with the agile team and look this looks similar to a scenario-based one as well and the business owners the scrum master recommends using moscow as to help prioritize the work with the product and the business owners and oh isn't this great so the product owner technically should have a prioritized backlog of features that they want to deliver being a customer so

they represent the customer but sometimes we need to work with them to help prioritize that list because maybe they come from the business or they're a customer themselves they don't necessarily know how to prioritize things based on value and cost and effort and so these things are really important so how does moscow prioritize the product backlog let's have a look okay it's more a must-have question which is totally fine but using priority one two three and four it's not that using low medium high it's not that using must have should have could have and will

not have uh must have should have could have and will not have that's our moscow approach it's probably that one using multiple dots that people can assign to features they like that is called multi-voting and that's also a really good way to prioritize now if we get stuck we can have people vote on it they get five dots and they can put it all on one feature if they really like that feature or they can put it across multiple features if they want a range anyway i think we're going to go with answer c here

answer c the moscow method of prioritization labels tasks as must have should have could have and will not have or would like to have sometimes if you wanted to go that way other prioritization techniques are multi-voting with dots monopoly money kano analysis based on benefits or value sometimes and the fist of five so just doing a simple vote agile teams use different methods to manage their work in progress or wip the business sponsor believes that removing the limits to work in progress will oh okay so in other words that limits how much work we take

on during a given time box or a given iteration usually around two weeks so we can't take any more work on than this this amount for example okay now it looks like the business sponsor believes that removing that work in progress limit will help the team take on more work and get their product delivered faster okay this is a common thing and this will happen all the time you know someone from the business or the customer area we'll say look why don't we just push all of this work through as fast as possible and okay

and usually with that it actually has an inhibiting effect so it actually has the bad effect on it on our team because they're working so hard and they're context switching between different tasks and that takes time to get up to speed on the new task as well so this is actually it's counter-intuitive you know it's not what you might think and that's the beauty of having an agile framework to deal with this so what are we going to tell the this business sponsor you'll remove the work in progress limits to push as much work through

as possible probably not based on that we need to understand this and that it's actually not going to have the effect that we want you'll dictate over time and no holidays for the team to get things done now look you'll probably see this happen in your business and in your career this will happen probably not the ultimate best approach you know it can work and it can work for a while but over time it will reduce morale and it will burn out your team and then ultimately it'll have the opposite effect that you want work

in progress limits ensure the team focuses on one main thing at a time and avoids the time cost of switching tasks so every time you switch a task from this one to this one to this one it takes you it might take 10 minutes it might take one hour it might take two hours it might even take longer to get up to speed in order to get the work started on that next task so there's a massive time cost there not to mention you know that it reduces the morale because you're pushing too much usually

more than what a person is capable of and work in progress limits are set with a reason in mind and so work in progress can be seen on the kanman board so it doesn't matter what the limit is uh look i mean kanban board does hold the work in progress limits so however many cards are on the board but that's why we have the limit in place let's go with answer c i've waffled on for too long already answer c that's great in agile work is taken on based on the team velocity or rate of

work the kanban board shows that work in progress and who is working on what which is why it's so great and knowing the velocity allows you to ensure enough work is taken on but not too much research has proven that multitasking or switching tasks actually reduces the effectiveness as the team gets up to speed again exactly what we were saying that was our first question i hope you did well let's get into the next one and we can go a bit faster for this one i think you're working on an agile team that includes many

stakeholders who have not worked with an agile project in the past okay this is going to be good several stakeholders have some valid concerns about uh some agile methods okay fine as a servant leader or a project coach which is your typical agile role what will you do to make them more comfortable with the process okay this is good will we educate the stakeholders address their concerns and keep them engaged that seems promising um this is a collaborative approach and our and our servant leadership we're growing our people we're informing them we're not just you

know not dictating and we're not you know hiding away even so we're still directly confronting the situation uh b tell them that it's worked in the past so it will work here too ah look some people may do this probably not the best approach especially from a servant leadership point of view we want to be growing and removing blockers dictate to the stakeholders that this is how all future projects must be executed now some people may have the power to do this like an executive but even then if you tell someone to do something and

they haven't taken it on board what's the saying um those convinced against their will are of the same opinion still so if someone doesn't believe it and doesn't believe in it themselves then they're probably not going to do it over time so you know that's a really great saying and that's why this one is not going to work either even though a lot of people will take that approach and d go back to a waterfall style project management method now look waterfall has its place sometimes we need to use waterfall in low risk environments where

we do just need one big bang release and so you know that's valid but in this scenario we want to be a servant leader and we want to coach and educate and bring everyone on board on the journey so i think we're going to go with answer a and here we are answer a a servant leader includes the team in decisions and grows the team through education and coaching and that's the beauty of an agile leader and the way that they will lead the way that we're determined to lead in agile how did you go

let's check out the next question you're working on an agile project with stakeholders who are keen to know why is it so important to incorporate multiple touch points with them before during and after iterations oh this is good to raise and manage changes to identify potential risks and issues that seems perfect to me that's why we touch base that's why we interact with people okay to inform stakeholders of the development team's direction uh not necessarily the product owner should give us a direction by having a prioritized backlog of features that they want delivered c to

ensure executive business executives hear about the team's value with multiple meetings uh yeah not that one you know you may have multiple meetings but that's not what agile is necessarily about especially from reporting to an executive point of view and d to have them invest more time in the project so they are more committed ah yeah not that one either so definitely from an agile point of view we're wanting to interact frequently so that we can change and adjust if we need to let's go with answer a answer a frequent touch points in agile are

there to ensure the business features are reviewed regularly and they meet the stakeholders expectations and that risks are addressed throughout the entire time that they're being developed this is really great and that's why you know stand-ups work and demonstrations and reviews of the product work and retrospectives work as well it allows changes to be raised early quality is everyone's responsibility because we're always talking and interacting and checking if we're delivering the right thing this is great all right i think we're on the next two questions last two to go teams let's check let's jump into

this one teams use daily stand-ups to micro commit to each other wonderful a good start uncover and remove blockers and ensure that work flows smoothly through the team what is not true about standups well they're often time boxed to 15 minutes that is true the team walks through the kanban or the task board that is true the team facilitator or anyone in the team can facilitate that's also true it doesn't have to be the scrum master in fact the scrum master should encourage team members to facilitate as well and grow their own leadership skills and

servant leadership skills and lastly only people in the project team can attend there's our incorrect answer there because we want to be open and transparent and that's part of you know if someone attends from another area and they actually have an idea that's going to help us with our project we want to know and that's part of the interactions and the benefit of the interactions in an agile approach so let's go with answer d as the incorrect correct answer there it is agile teams are open and transparent and encourage stakeholders to pull information and work

when needed anyone can attend or learn or watch or contribute and stand-ups are time boxed to 15 minutes the team walks through the kanban board usually and anyone in the team can facilitate as well and should be encouraged to do so now we're on our last question great job guys we're there you nearly did it let's see how this one looks features are completed in an agile project usually in the form of multiple user stories that's right so multiple stories make up a feature that the product owner really really wants and has prioritized so high

or low when should we deliver it the feed when a feature is complete the team periodically demonstrates the working product to the customer that's a demonstration or a sprint review so at the end of a sprint what have we created we're showing our customer the business representative and or the product owner who represents the customer all the business these demonstrations or reviews only occur at the end of a project when the stakeholders are available no at the end of each iteration we want often occur at the end of an iteration yep or when enough features

have been completed into a set that is coherent now that's important as well you know sometimes we don't have anything to demonstrate because we're still working through it and it's a little bit complex but for this one this is correct because sometimes we have enough stories to have been put into something usable and we can actually showcase that so i think we're going to go with b let's look at the others often occur at the start of a project no because we haven't developed anything to show yet so not that one and often occur when

the team wants to uh as they're so busy working anyway yes we're busy and that's why we have to prioritize this time to interact with our customer and make sure that we're doing the right thing so let's go with answer b as the correct answer here there it is agile sprint reviews or feature demonstrations occur at the end of an iteration or when enough cards or features have been completed into a set that can be showcased try saying that three times fast although maybe i just got tongue tied and maybe you can do it and

just like you've also done these five agile questions and have automatically improved your agile knowledge disciplined agile is a process decision framework wow that blends various agile techniques and oh this is going to be good so which of the following principles are not a part of disciplined agile and look this question is really important whether you get something like this in the exam or not because all of the different frameworks that you'll see that make up a part of agile actually have the same principles the same core principles and so all we have to do

in situations like this is just figure out what what has the same core principles as the agile that we know today and so this is really fun and really important so let's check them out we've got people first enumerating roles and organization elements at various levels okay that sounds pretty full on but definitely people first is is a big part of agile so we could say potentially for that one learning oriented definitely we want to have the growth mindset we want to make mistakes and improve we want to iterate and get feedback and we want

to encourage feedback so i would probably say learning is a big part of agile today and that's going to be a part of our of our you know other agile frameworks as well and especially collaborative improvement yes so that's our iterative improvement getting feedback okay self-promotion working to improve your own personal brand okay this one sticks out like a sore thumb because agile is more about the team and interacting as a team isn't it it's not really about just promoting our own personal you know brand or our own work it's about promoting the team's work

and helping as a team so that one's looking like that stands out at the moment goal driven is the last one tailoring processes to achieve specific outcomes oh and i absolutely love this because you'll see different flavors of project management and different flavors of agile in your organization and and you know you'll have to tailor your approach to suit those circumstances so you know you might have low risk or high risk or different people with different you know different goals or different initiatives in mind and you might just have to tailor things a little bit

so it looks like for this one the correct incorrect answer we're going to go with answer c answer c agile works transparently for all with all stakeholders in mind really really great great part of the reason why we use agile self-promotion is not a part of the agile way instead the team serves each other and ensures that blockers are removed for each other as well and that information is freely available whether you're in the team or if you're outside the team it doesn't matter that information is always there it's a transparent environment that was a

lot of fun all right let's check out the next question uh okay great another one so moving into all these different agile approaches so this is going to be a lot of fun disciplined agile is a process decision framework that blends various agile techniques which of the following principles are from disciplined agile okay so we're going the other way now this is good learning oriented goal driven and scalable that definitely seems promising because we saw goal driven before we saw learning oriented feedback and scalable ultimately we do want this approach to scale you know we

might use a scrum of scrums for example where we've got a few different scrum teams and you know and now they're representing all together and having one scrum of scrum so you know across all of those different teams at a program level let's see the other ones uh implementing iterating and integrating look i mean that sounds fancy but it's it doesn't really match up with the the agile approaches to you know directly excellence guidance and cadence um again uh some of these are just words aren't they it's like i don't know do these really go

together i'm not i'm not super sold on that and making doing and being okay uh look i mean i think out of all of these being learning oriented and team oriented is probably the best bet from an agile perspective let's go with answer a for now answer a this is great learning oriented goal driven and scalable are all themes within agile in general and are key principles of the disciplined agile framework which was really a core part of agile in early days as well all right how are you going a couple of questions to go

you're doing great let's get into this okay another different framework this is good so all of these will make up and we're a part of agile in the early days dynamic systems delivery method or dsdm is one of the founding methods with an input into agile it was designed to add more rigor to the rising iterative methods of the 1990s like crystal uh you know and all the different things that came out of ibm and you know so all these things that were really new at the time which of the following are principles from the

dynamic systems delivery method dstm framework let's have a look and we can say we can apply the same approach here what matches the agile that we know today uh and you know let's let's see so focus on the business need and deliver on time oh i mean absolutely because we're always meeting with our customer and we're meeting with uh the product owner who represents the customer or the business or the people that we're delivering the value to and they get to prioritize that value they get to say look you know this one we want this

one this one's number two this one's number three they're the ones who say what is most valuable to the customer and to the business and you know that's really important and delivering on time uh even though we might change these features around for their priority we're still still delivering value on a regular basis i really like that one um okay add every feature and stop when we're done probably not correct because we'll be prioritizing those features we won't be adding all of them maybe we'll have to get rid of this one or maybe we'll have

to bump this one down and bump another one up so that's where the product owner comes in to play and prioritizes that value again uh so probably not that one find all the defects or don't approve the release okay one of the main things of agile is certainly quality so we definitely want to be releasing a quality product quality is everyone's responsibility from our you know from our business analysts to getting the requirements from the product owner uh and through to our developers through to our quality analysts or testers uh and even you know ultimately

through to the release itself so all of those chances have a fine uh have a chance to find those defects as we go along the journey of delivery uh and so but i don't think we have to find all of them yes we want to but that's not how yeah how do we know what we haven't found so this is a little bit of a fuzzy question sometimes you just don't know what you don't know and that's part of the reason why we release small increments that are a little bit lower risk and then we

can see if anything has gone wrong there and try and improve from there that's not to say that we want to release with defects but we can't stop a release based on things that we may not know so that's a tricky one i probably wouldn't say that one push fast delivery over quality so we can learn from our mistakes learning from our mistakes is really important that's part of iterating uh you know so we're wanting to iterate and get that feedback and improve but uh we don't do that at the expense of quality like i

said you know as we as we've seen quality is everyone's responsibility through the whole value chain from the requirements through to delivery and so yeah look i mean that one's a little bit tricky as well but the the one that i like the most here is focus on the business need and deliver on time let's go with answer a all right this is good that was a bit tricky a dsdm focuses on the business need and delivers on time scope is often variable well that's right and so we might have variable scope we might be

changing those priorities as we saw and it can change as with all agile frameworks schedule is often set however so we have a certain amount of time to deliver those features or whatever we can get done in that time so the features must be managed within the product with the product owner and with the backlog that was a really good one i like it and i think we've got two questions to go this is a good chance to practice your agile and to practice your project management questions for your exam and now we're starting to

get into a little bit more uh general questions so this is going to be a bit more fun you're working with the developers in an agile team who are using a test driven development approach okay this is great and this is where we test first and uh technically it should fail because we haven't written the code yet then we code it up and then we run the test again and technically it should pass because we've written the code to the solution so we're writing with the test in mind and with the with the outcome in

mind it's pretty cool approach and it's very useful um so they ask you whether you they should operate using something called a red red green refactor what are they referring to okay this is great well this is uh you know much more technical now so let's see what options we have uh when okay red green or refactor so refactoring is where we uh where we go back into the code and we just clean it up so maybe we you know maybe we we hone it down a little bit maybe we wrote something maybe we did

like a bit of a hacky solution you know sometimes just to get it through uh and maybe we want to go back and we want to clean that up to to help people for the future and to make sure it's easier to work on in the future and also to reduce you know the size or you know or the the slowness of the application by doing that as well refactoring is a really big part really important um so okay where no code is developed during a red status some code is developed during a green status

and new features are taken in during refactor so knowing what refactoring is i don't think it's that right so let's see a traffic light approach to bringing in new features again that doesn't match refactoring so it doesn't mention that let's leave that for now only releasing features when they are given the green light you know possible but again not really lastly where a test is written first that fails oh good oh because we're talking about test driven development okay this is exactly what we were saying at the beginning that's handy test written first it fails

then it passes once the solution is developed exactly as we were saying and then it can be refactored or streamlined wow so okay in in explaining all of this we inadvertently answered the question for ourselves so i think it's pretty obvious let's go with answer d answer d the process of writing a test test that initially fails adding code until the test passes a bit of a hard thing to say for me and then refactoring the code is part of test driven development tdd so red green refactor is the same as fail pass and then

streamline the code which is that whole makeup approach for tdd great so that was a really that was a fantastic question really good knowledge out of that one and now we're on to our last question let's get into this one you're doing great keep going you're an agile project manager and you're working with the product owner of the agile team oh this sounds great there are several key develop deliverables that have been identified and listed in the product backlog this sounds fantastic this is exactly what we want in an agile team now what will the

agile team do next and this is good we have a scenario based question this is exactly the kind of thing that we're going to see on the pmp exam so you know good on you for sticking through it because this is really important this is a good one okay all deliverables should go live only at the end of the project no we want to be delivering in increments little features of value that we can see feel and touch and and get that feedback on so no not that one uh the tasks should be delivered but

not tested to get value to the customer as quickly as possible no not that one either so we do want to test and as we saw before quality is everyone's responsibility we want requirements to be you know to be gathered properly we want them to be developed well we want them to be tested well and we want the release to go smoothly and it again and to get that feedback quality is everyone's responsibility the tasks should be prioritized developed and tested incrementally wow okay now that sounds much better that's exactly what we were saying let's

put that one aside probably going to be that one and tasks should be planned carefully and delivered according to their plan now planning is important yes it absolutely is but in agile agile manifesto we respond to change over following a plan so following a plan is still important but we prefer to respond to change you know more than following that plan really really important part of agile and part of what makes it so powerful and so i think you know even though that one is definitely true i think the best one for us is going

to be answer c answer c agile develops and delivers in features or increments this means prioritizing for each increment or feature that we deliver and we test for each increment as well even though we want to deliver quickly quality testing is still important and quality is everyone's responsibility well that's exactly what we're saying i think we're getting pretty good at this by now we've been through a few questions together and i think you're improving your knowledge and even i am too so this is really really wonderful a team new to agile has worked closely with

the product owner and has identified the highest value features of the project oh and isn't that just wonderful that's music to my ears and when when you've worked in agile projects for a little while you'll understand how important that is to have someone who represents the customer and can prioritize that value and elaborate that high level really quickly that's so important so what is one reason to break down those features into increments and deliver them as soon as possible oh wow what a wonderful question and this is really truly the heart of agile so let's

check it out to get all the work out of the way so the team can relax now uh i'd love to relax but sometimes we still have to keep working it's probably not for that reason so we do want to do our work and we want to do it well and we do want to relax as well but that's probably not the core reason why we're doing this so the project life cycle can be shortened i mean not that either we usually we usually have a fixed fixed time frame and we want to be releasing

multiple features within that time frame uh so the product owner can report to her executive manager uh that work is being done uh look people will do that for this reason sometimes people will only do the work so they can you know look good or improve their own personal brand or you know or basically do it for their own outcome but for agile we're working as a team we really want the team to be be the winners here and we want yeah we want everyone to be feeling good as a team and doing the work

as a team so probably not that one even though you will come across it in your career uh last one to reduce the risk of the feature no longer providing value for the customer wow okay that's an interesting one so we're wanting to break it down and deliver it as soon as possible so that it still has the chance to be adding that value to the customer i mean definitely it we've got customers we're reducing risk those are all things that we're wanting to do in agile i think probably out of all of those that's

the most prominent well let's go with answer d for now answer d the longer a feature takes to deliver the higher the risk is that that feature will no longer provide the value that it was intended to provide and that's you know you see things moving so fast these days that certainly can be true maybe if it took another five years to deliver the original iphone maybe someone else would have done it maybe not of course but it certainly has changed the way that we look at things now hasn't it and now that cycle is

getting shorter and shorter to releasing the next one and the next one and the next one so value driven delivery prioritizes features by highest value and delivers them quickly for maximum customer benefit i think that sounds pretty good to me all right how did you go let's go into the next question you're an agile project manager working closely with the scrum master and the agile team and the scrum master mentions that agile works differently with risk compared to a traditional project okay now look risk is still important so let's see where they're going with this

he sets a meeting with you and the team to talk through agile risks what will you do to ask next okay this is going to be good ensure the team notes and schedules high risk activities early in the project so they are mitigated quickly that sounds pretty good to me i like that one and you do that on a normal project hopefully as well actually so this is where we start to see the flow on and and how things work together just on a normal project as well it's just because it makes sense uh okay

ensures the ensure the team identifies risks places them in a register and mitigates them by the end of the project look that's also important and a decent approach but with agile we're actually wanting to work on the risks uh first to get those risks uh out of the way basically to reduce that risk so i think we're still with a on this one ensure the team keeps the risk registered to itself so other stakeholders don't think less of the project now you'll see this happen in your career people might just not mention risks or may

keep them to themselves and that actually has an adverse effect because then maybe you're releasing something that may not match what you're wanting it to do or for the customer so definitely that one's not a good one for us and lastly ensure the risk is only captured around people because an agile team prefers individuals and interactions over processes and tools uh okay i mean even though agile does prefer interactions in individuals it's basically risk is for everything and a whole part of the project so i think we're going to go with ansa a for this

one answer a an agile team delivers in increments and iterates towards improvement by prioritizing high risk features first future risks for the project are reduced and that is a wonderful way to work so that's a good one all right how did you go let's go on to the next question you're a project manager on an agile project that requires an external third party this is great this will happen a lot in your career as well you'll see this happen all the time to develop software for one of your features you've worked with the project team

to gather the requirements and the backlog of product features we're doing well so far that's good you begin working with your procurement department so these guys are the ones who do the contracts and that sort of thing for our third party on a contract for the vendor what will you do next oh wow this is a great one let's have a look request that the contract is one that accommodates changes to product scope okay now this is important because agile is all about responding to change over following a plan so if typically if we have

a contract everything is written into the contract and it's locked in and oh no you can't change and oh if you change then there's penalties and so that can really inhibit the agile way of work and inhibit us from finding things out as we're going along which is also an important part of the approach so maybe writing that into the contract can help i think i like that one let's check out the others go back to the business and ask them to deliver the feature okay uh i mean sure that's one way that we could

do it maybe the business uh or or part of the original organization could deliver this instead this is a maybe raise a risk to the delivery of your project based on the external vendor i mean yes that's going to be a part of it as well there is risk around this and we will have to raise the risk and we'll have to have risks and controls or mitigations for that risk and that's actually a good answer as well in a way and lastly find an existing time and materials contract from the organization's organizational process assets

so time and materials it typically responds to change because we're just paying for the time involved and the materials involved in creating whatever it is that we're creating but the thing with time and materials is if it's not clearly outlined enough then you know that could just keep escalating on and on and on and on and there's no real incentive to deliver because it's you know the more time someone spends on it the more they get paid so we have to look at our incentives here uh this is a really tricky question um and i

love that it incorporates risk and your third party and procurement all of these things that you will see in the pmp in the pmbok as well look as tricky it is let's go with answer a and hope for the best okay that's great agile works with changing scope and cost as the product is completed incrementally but primarily a fixed schedule and quality so as you're working with the procurement department you'll need to ensure that the contract accommodates that those changing requirements and this is going to be good this is a good one to know for

your exam and it's your really good scenario based question as well about all of those extra flavors of project management that you will come across that was a great question we've got two to go let's jump into them dynamic systems delivery method dstm is one of the founding methods with an input into agile designed to add more rigor to the rising iterative methods of the 1990s like crystal and scrum and all of these other things it's most known for its emphasis on constraint delivery constraint driven delivery which sets cost quality and time at the beginning

and then uses formalized prioritization of scope to meet those constraints wow that's a big mouthful but what they're saying there is that score that scope is variable and we vary it by prioritizing the the best features that the customer wants first so we deliver those features as quickly as we can and then if we have any time left because time is fixed then we can deliver the lower priority features at the end so that actually is pretty good i like that one and that's what you'll find in agile in general so we know that that

is is true single delivery uh which ensures everything is correct and approved before the project goes live um if it's agile we're probably doing incremental delivery of features so it's probably not this one stakeholders which ensures that everyone is involved in gathering scope quality and cost requirements uh i mean sure we do want the whole team approach so you know the whole team can be involved emphasis on stakeholders maybe not the highest emphasis so that's a maybe that one and lastly cost which ensures that the project closes once funds are depleted look and that may

happen but of course there are different variables around that maybe more funds will be released or maybe we will just i think the highest priority is really around the scope and changing that scope even though the other things are fixed so even though some of those are good answers the best one for us for from an agile prioritizing value point of view is answer a let's check it out answer a agile methods as we know them today work with a variable scope while cost quality and schedule or time are often set in stone and this

is the opposite to a predictive waterfall method which sets the scope up front and the schedule on the cost and then just works to deliver in one big bang right at the end okay that was really good these questions are fantastic and we've only got one to go you're doing great i just keep at it the learning that we're getting from this is fantastic and it's going to help you so much last question for us agile projects have short iterations enabling the project team to receive early and continuous feedback on product quality throughout the development

cycle one of the benefits of agile by getting frequent customer feedback as the project progresses agile teams can incorporate most new changes into the product and the development process before you know the end of the project okay this is good so far what is not one of the benefits of this approach okay avoiding requirements misunderstandings that is a benefit and so that they may have not have been detected until later in the development cycle that's why we get that feedback uh and so that's really important and at the end of the development cycle they're much

more expensive to fix so we want to do them as quickly as possible that's good clarifying customer feature requests making them available for the customer use to use early that's also a good one we want that one discovering isolating and resolving quality problems early we also want that that's one of the reasons why we do agile and get that feedback and release the features to get that feedback let's have a look at the last one having one big release at the end of the project that everyone can celebrate uh not for agile so even though

that can be an approach that we take and certainly it has its value it's good celebrating these things as well uh you know but for us we want to be releasing increments so that we can gather that feedback as we go so the correct incorrect answer for us today is going to be answer d answer d agile methods work with multiple features releasing them in increments so the customer can use them and provide that feedback having a single release is a waterfall approach and waterfall's not what we're talking about here today even though you will

still come across it and this has been the most fun i love talking about these questions with you and i love working through these to help us prepare for the pmp exam or the agile certified practitioner or any other agile certification that you are going for this knowledge will help you so much and don't forget we'll be looking at some scenario-based questions and some knowledge based questions just to really round out everything that we may need to know for the exam or just for agile in general this one let's get into it what have we

got enterprise scrum is a framework designed to apply the scrum method at an organizational level not just within a single product development effort what is not a part of leadership within enterprise scrum so this sounds like a scaling method so we're wanting to you know take multiple teams where we have projects and also now this goes into a program level which is our you know scrum of scrums and and that sort of thing let's see what we've got here extending the use of scrum across all aspects of the organization okay that looks good to me

role playing the role of scrum master before the first iteration um that could add value maybe we'll put a maybe there generalizing the scrum techniques to apply easily at those various levels it sounds like we're wanting to scale the the scrum approach so we're wanting to do that we're wanting to basically generalize things so they can apply across the organization not just in a technology driven team and scaling the scrum method with supplemental techniques as necessary and of course this is tailoring our approach which is part of what we do in an agile project or

any project we tailor it to the situation that's at hand so i like that one too and probably the only maybe here is a role playing the role of scrum master before the first iteration now that can have its own value but i think that's not the main issue at task here so let's go with the correct incorrect answer as being answer b answer b choose uh so all answers are correct except b we're role playing this the role of scrum master while you may choose to do this it's not a part of enterprise scrum

which is all about scaling the scrum methodology oh there you go to use it across teams as well as within teams that was a great question alright let's check out the next one you're an agile project manager tasked with evolving your part of the organization into agile what is not something that you would do when making this change okay treat the change as an agile project with its own backlog of changes that could be introduced by the team based on perceived value wow that's perfectly agile we're prioritizing value we're delivering the highest value first ideally

we really want that one treat each of the changes as an experiment tested for a short period of time to determine suitability or the need for further refinement i mean yes i like that one too it's sort of like delivering features and getting that feedback which is our iterative approach i think that one's really good use kanban boards to track progress showing new approaches in use as done and things to be tried as in progress this is also really good so uh you know we're using agile to deliver value uh to deliver agile so i

think that one's good too let's see what the last one is direct the teams to take on agile in one go moving ahead without wavering uh you know this happens at in organizations all the time and it's actually opposite to the agile approach it's more of a waterfall approach isn't it so the correct incorrect answer i think for this one is going to be answer d entity agile is an incremental approach where we're delivering in increments or features using a backlog of agile methods the team would like to use treating them as an experiment and

using a kanban board to track progress are all things that you can do to use agile when implementing agile that's a really good way to look at it too i think that's a this is a really really good question and and you know it's good to think about using agile when we're trying to implement it in our teams that was really great all right let's check out the next question extreme programming oh this is one of the big ones one of the really core inputs into agile it's a software development method based on frequent cycles

does that sound familiar maybe iterations or sprints it's known for popular popularizing a holistic set of 12 primary practices later expanded to other secondary practices it outlines requirements such as and remember when we're looking at these frameworks remember the core ideas behind agile today and you'll find that that was a hat that's what had the input into agile so we know what to look for things like you know using a value-driven approach delivering in increments that sort of thing so to sit together in the whole team approach in an informative workplace so informative workplace being

our kanban board being our sprint burn down shard for example and also to work together as a team this certainly sounds very agile to me so i like this one to write reports for the executive team uh probably this certainly doesn't come up as one of the core agile practices does it even though we may have to write reports for the executive team what we actually prefer is for that for the executive team to come and visit our informative areas to see the burn down charts to see the kanban board and see what's being delivered

so that's preferable so this is probably going to be the wrong one here um rotating the roles so everyone gets experience in something they like uh i mean maybe but probably not and developing all changes for a single release definitely not that one because we want increments as we know and rotating roles you can do that but also we want people to be specialists in one area it's the t-shaped uh t-shaped person basically we've got like a large range of experience across different things but then one really deep specialty so that's our t-shaped person our

generalizing specialist so i think the correct answer for us is going to be a for this one answer a agile core practices include the whole team approach and an informative workplace such as visual management using kanban burn down charts and backlogs this should give you a hint at the answer for extreme programming which is a core part of agile that was a really good one all right we've got two questions to go guys you are doing fantastically let's jump into them you are an agile project manager working with the project sponsor in the beginning stages

of an agile project the project sponsor mentions that they would like your help creating the project charter you tell them that you will also do a team charter for your agile team that will include the project sponsor what does this mean so this means you'll capture the team values communication guidelines and decision making process separately to the project purpose requirements and summary schedule even though that's a lot of words that actually does sound correct we're focusing on the team how we interact as a team what do we promise to do to help the team work

together what are we committing to as a team okay you'll create a project project plan with scope schedule cost and quality outlines to follow that's more of a project management plan so not that you will take over from the project sponsor and direct the team on future customer requirements uh definitely not that um you know we want the team the team will go through the agile approach prioritizing value to do that i think and you'll defer to the team for all queries in the way of a servant leader oh i mean that is fine but

also we want everyone to have an approach uh to have an input into this so i think really team charter we want communication guidelines and decision making process and team values to be captured as part of our team charter and that's answer a let's have a look answer a an agile project manager charters both the project and the team a project charter focuses on the business case project purpose high level requirements stakeholders and risks in a traditional way a team charter focuses on the agreements in how the team will operate and how and it's created

by the team for the team all right that was really good and you'll definitely have to do that as part of an agile team focusing on how we're going to work together and what do we agree to do to help each other out all right we're on to the last question well done you made it let's see what we've got hopefully it's not too tricky you're working with the team on the team charter oh that's very handy we've just been speaking about that and you've outlined the project division mission and agreed meeting times and accepted

team behaviour what will you do next ask the team to get to work straight away because agile teams move swiftly i mean that sort of but not really send the team charter to the project sponsor for their sign off so the project can begin well the project sponsor should be a part of the team ideally so they should be agreeing to these team values at the same time with the team so probably not that one agree on and include the definition of done oh this is good for team features and tasks and this is you

know how do we know when something is ready to be released well it has gone through it's had proper acceptance criteria it's been developed it's been tested the tests have passed maybe it's been signed off by the product owner and checked by the product owner or a subject matter expert expert in that particular area so all of those things might have an input into our definition of done and that's actually really important to define so that's good i like that one set a meeting for two weeks time so so you can continue to develop the

charter iteratively okay so and this is where we need that middle ground because we've got answer a which is getting to work straight away you know sure we're working straight away but we're not rushing into things necessarily so we're not in a rush but also we can't wait two weeks for a meeting to come about either so really we want to define what done means for our tasks and for our project let's go with answer c answer c the definition of done is important is an important part of the team charter to ensure the team

knows when a task is completed when they can pull the next tasks and so everyone agrees what success does look like this could involve a card being defined elaborated developed tested reviewed and then released exactly like we were saying just before and the project sponsor should or might be included in the team charter but it does not but they do not need to sign off on the team charter it's an agreement amongst the team and that is the last question how did you go i think that was really really great some great questions in there

and definitely concepts and ideas that you will see on the pmp exam you are working on an agile project gathering requirements from the business stakeholders with the product owner uh that's exactly what we want to be doing product owner should uh have the the features that we want to be delivering they should set the scene for what we want to be delivering as well during the discussion different people seem to have different understandings of what the feature will look like what will you do next and this is a great example of a scenario based question

uh really important you'll see a lot of these on the on the pmp exam and these are really can be quite tricky more real-life scenarios this is exactly what we're looking for so this is great uh so what will we do we'll ask the stakeholders to elaborate their ideas better i mean maybe and set another meeting in a week's time definitely not that so i mean even though we don't want to rush things but we don't want to take too much time and really the idea of agile is having all the people close together so

that we're talking uh on a regular basis like really regularly like so that we can literally look over our shoulder and say hey bob you know what do you mean by this feature we're not waiting a week that's not that's not what we're here for okay park the feature for now and begin work on a feature that is elaborated better i mean certainly that is one option that's something that you might do in the real world as well you might wait but again we're more about communication here so we really want to be communicating and

figuring this out in the moment if we can let's see what we've got draw the storyboard draw a story storyboard prototype of the requirement so all stakeholders can see it adjust it on the fly and agree okay this looks very promising because we're doing it in the moment and also feature driven development which is part one of the things that that feeds into agile one of the methods that feeds into agile feature driven development starts with a high level model an idea a model of of the feature and then you hone it down and you

hone it down and you hold it down and you hold it down and it becomes more and more accurate as you're iterating over the different uh you know iterating through those versions uh so that sounds very promising i like numbers i like letter c at the moment give your understanding of the feature and ask the stakeholders to agree or disagree and again look that's one way to do it and all of these are things like facilitation techniques that you can use in the real world but from an agile perspective i think what we're wanting to

do is communicate and also what we're wanting to do is iterate and improve go through iterations if we can starting with a high level wireframe or a prototype so let's go with answer c for now answer c gaining consensus regarding the content and flow of a piece of software by developing a wireframe or storyboard will confirm everyone has a complete understanding of what the output is and we can see it as well in a way it's actually an increment like it's a it's a you know not not very well developed increment that everyone can see

feel and touch and now we can really figure out if this is what we actually want so that's a really good answer and a great question too how did you go let's check out this next one you're working as a project manager with an agile project team okay fantastic the project sponsor sits on another floor and prefers to communicate by email only okay uh definitely gonna have some problems here working in an agile team because we want to be face to face ideally and we want to be communicating often uh and talking on a regular

basis interactions and individuals um as the main focus of agile what will you do next ensure that you communicate by email only with the project sponsor so they are comfortable uh i mean look definitely that may happen in the real world i think we're not going to go with that as the best answer from an agile perspective stop communicating with the project sponsor until they at least come to a few project meetings uh no that would be avoiding the situation and we prefer to be direct in our communication but also collaborative in our communication as

well so ask the project sponsor to co-locate with the agile team for a few days a week to ensure face-to-face communication and access to the visual project information oh now this this is really good this one so co-locating now the project sponsor we can say hey anne as a project sponsor what did you want when we're delivering this feature is this actually what you wanted and ann can say well no that's actually not what you know that's not what i had in mind at all and you can adjust it on the fly the communication is

fast and that's one of the powerful parts of agile also ann can see by sitting with us as the project sponsor the kanban board in our visual area uh she can see the the burn down chart where you know where we're creating finishing cards and putting those towards features and see how fast we're going and the velocity of the team so how many point story points are we completing in a sprint even though she doesn't have to be involved in all of those things all of those things being absorbed as she's sitting in the area

with us will really really help so last one set meetings with the project sponsor so you can update them personally look i still think we're going to go with answer c here let's check it out answer c an agile project team aims to work in a co-located space where ideas and information can flow freely face-to-face communication provides the best opportunity to ask questions get immediate feedback and understand body language as well in order to acknowledge agreement or clarify misunderstandings kanban boards and other visual tools are also in the team area as we were saying and

the the whole thing about uh face-to-face communication here uh you've probably heard and look the the percentages differ here but i think only seven percent is actually the words we speak of someone's understanding and communication so the rest of it comes down to things like the verbal like the way we say something so the intonation and the other things we might have are the body language so body language how is someone shifting their body are they saying um yes yeah sure i will do that absolutely you know then we see that there's definitely probably going

to be a problem there right so you can't see that if you're not in the same room and that is the power of co-locating your team as an agile team all right let's get into the next question as an agile project manager you understand the need to operate with openness and transparency with your team and with your stakeholders this is a great principle in general how will you encourage knowledge and sharing throughout the project okay this seems good okay tell your team what to do during work hours so they can learn from you okay no

as an agile project manager or a leader we're not dictating we're being a servant leader so we're helping our team grow and we're removing blockers for them so that is more dictating not that one for us writer process documents for the team to read through in their spare time and we're looking at individuals and interactions over processes and tools that's from directly from the agile manifesto itself so into individuals and interactions we prefer we're not really focusing on processes your own tools even though they are important we prefer to focus on the individuals and the

interactions and working together and communicating so again probably not that one let us see make key information visible in the team area and ensure all impacted stakeholders are invited to the daily stand-up retrospectives and even iteration planning oh this is good yeah i mean that's perfect for knowledge sharing and this is it we don't have to have extra meetings we're already having the right meetings and because we're transparent as an agile team we're not hiding everything away we really want everyone to come along to these catch-ups and they can get everything they need from these

stand-ups retrospectives iteration planning meetings backlog refinement meetings all of those things let us see is looking really good for us here last one form a key group of executive stakeholders to share project information with and ensure your good reputation within the company yeah look i mean i still would go with letter c here you know again people will focus on their own personal brand when you work with them on a regular basis but if you're truly moving towards an agile team you look at other people and serving the team as opposed to just serving yourself

and that's one of the benefits and that's that's one of the things that makes it so powerful so answer c is what we've got an agile team makes project information visible and accessible to all agile teams also prefer people and interactions over processes and tools exactly as we were saying it's part of the agile manifesto that's a good thing to be aware of for your exam how did you go let's get into the last two questions you're doing great last two you've been working in an agile team for some time and an executive from the

business area asks how the team has been able to deliver so consistently over the past year you tell him you're using extreme programming or xp what are some of the primary practices of xp that contributed to the team's success and if we're talking about frameworks in agile and there are there are dozens dozens of frameworks that contributed and that make up agile and that you'll come across there are scaling frameworks there are frameworks that you know kicked off from the original you know that fed into the original agile approach there are ones that are still

in use today you'll see these everywhere you go and different people have different variations but one thing you can count on is that if we're looking at frameworks look at the core practices of agile here things like servant leadership stand-ups retrospectives iteration planning meetings all of those things and how do they match up with what we're looking at here if they match up then it's a good chance that we're on the right track so that's what we're going to do right now so real customer involvement team continuity and a sustainable pace i mean well that

first one is a fantastic example of agile sustainable pace is a real key part of agile we're not working people you know high and then having them take time off and then working them really hard again we're not throwing you know hundreds of resources at things you know and having people switch tasks constantly and multitask no we are having people focus on their core domain so they really understand it and they're really good at it and then we're having them work at you know a sustainable pace that can go on ideally forever and that's the

main thing we're not over working we're not underworking i really like letter a at the moment and plus real customer involvement that's our product owner isn't it who represents the business and team continuity that's really important because when we've got team who sticks together now we're starting to get the benefit of people working together and getting better at working together and that only happens after you've been a team for some time it doesn't happen initially i mean if we you've got you're forming storming norming a forming norming storm or whatever it is forming storming norming

and performing that's right so when you first form as a team you go through that storming stage because everyone's figuring out where they fit and exactly how to work and that actually costs us you know time and money to go through and work through that stage and it happens every time anyway enough of me blabbing on i like i really like letter a at the moment ensuring executive reports testing continually raising defects no that's not a main factor of agile given away by the executive reports we want executives to come to our retrospectives stand-ups iteration

planning if they want to or to visit the team area to get the information that they need like a kanban or you know all the burn down charts and all the features that we're delivering pivoting frequently ensuring long meetings and one final delivery that's more ad more waterfall and lastly finding the right product finding the right people and finding the right price while that does roll off the tongue nicely none of those are part of our agile methodology in general so we work with the people so to deliver what the people want through the product

owner the product that represents the customer and finding the right people look you may find the right people or not but either way the idea is that agile gives us the framework to work with the right people whether we find them or not so i still think we're going to go with answer a and there it is the extreme programming primary practices include real customer involvement team continuity and working at a sustainable pace agile encourages all of these through its stand-ups backlog grooming with the real customer or the product owner and working to the team's

velocity and now that's great so each uh each iteration we're going to say look the team has completed in the last three months or the last three iterations uh you know on average 45 points or you know or seven medium cards for example or however you're measuring your cards it's up to you as a team and so if we're planning the next iteration we're going to say let's try and keep it around that same number of points because we don't want to overburden the team you know while some people might crack the whip some executives

might do that in your career that actually has an adverse effect because it overworks the team and then they burn out and then they start leaving and then you have to rebuild the team again so it actually has the opposite effect that the executive wants and that's really important to know not just for your exam but just in general as a manager as a leader as an agile coach for example as a scrum master last question guys you've done absolutely great let's check it out you're working with a seasoned agile team who are very familiar

with extreme programming in their way of work they walk through a set of principles that they frequently use what is not one of the primary practices of xp and again we can use the same approach as we did last time here planning with user stories yes i think we do that so iteration planning we put our stories into the into the iteration from the product backlog test first programming uh so test uh test driven is it test driven delivery yeah or something similar to that tdd um but that's where we're testing and then we're you

know and then the test will fail then we're coding what the the change that we want and then we're testing again and the test will pass so that's how we're doing test driven delivery uh incremental design yes we're wanting to design in increments and then release and then release and then release and then release we're not just releasing in one big bang of course that's waterfall last first in best rest uh that one you know that's a saying but it's not an agile or an extreme programming saying so let's go with d as the correct

incorrect answer here we are extreme programming works with 12 primary principles including planning with user stories test first programming incremental design and more all of these will align with the core principles of an agile way of work but first in best rest is not one of them and that comes to the end of our handful of questions to prepare you for your pmp exam and bring your agile knowledge up to speed you are testing the product being delivered by an agile team in increments that sounds very good that's what we're doing as an agile team

we're not releasing in one big bang we're releasing in increments it's an incremental approach or features or features that's also a good way to do it you notice that there have been no defects passed on to the end user you also notice that you're working with an extreme programming methodology for the team what are the xp practices that led to this result all right let's have a look so extreme programming practices but also general agile practices that we know that match up with xp because it's an agile framework let's see what we've got regular refactoring

and daily deployment of an integrated code base now what we're talking about here is regularly streamlining the code so basically you're getting rid of any extra bits or any loose ends in the code to make sure that it's easy to work with in the future and also potentially runs faster and runs better for us as well by we're refactoring so streamlining that code daily deployment of the integrated code base means we're deploying ideally the code to a test environment and then running an automated test so that we can see if anything has broken with all

the things that we've been developing so both of these things are they're actually a little bit more technical on the xp side but they are definitely a part of xp so uh yeah i mean i like that one having real users test the product when it's released i mean that is also a good one as well moving team members around to different roles for a shared experience i don't think we do with that one because we want team members to be the t-shaped team members of a team generalizing specialists where we've got a broad range

of knowledge themselves and then one deep specialty so we really want to keep them engaged with that one deep specialty that's the t-shaped or the generalizing specialist in the team and everyone ideally would be that kind of team member in an agile team ensuring the team does exactly what the scrum master says definitely not that one because the scrum master can guide us and ideally will help us grow but also we'll simply be removing blockers for us to doing the work in an agile team it's not up to them to dictate and you know that's

probably something's gone wrong if that's happening in an agile team so as far as extreme programming goes the it is a bit more technical but let's go with answer a there we are can extreme programming works with continuous integration that's one of its main things deploying a single code base on a daily basis and running automated regression tests so regression tests being testing the normal functions just to see if anything any of those normal functions have broken with our new code base in this way defects are picked up quickly regular refactoring or simplifying as we

said and cleaning the code also ensures that it is easier to work with and easier to pick up and fix defects and that's right and easier to work with in the future that was a great question so you may come up with some similar technical questions your partially technical questions you know we're not they're not asking us to code things but they're certainly asking about the coding practices that we might employ in an agile team that was a really good question all right let's check out the next one you are an agile project manager working

with an agile coach and planning the next sprint with the team the agile coach advises you to build in some slack for the sprint what does this mean and this is awesome this is such a great question you will have to do this in the real world as well and you know sometimes it doesn't it doesn't always work out this way but but it is such an important practice to put in to use in your real work as well so uh to use the what does it mean basically is what we're asking to use the

messaging service slack to communicate as a team uh definitely it's not that although yes slack is very popular at the moment allowing the best performers in the team to slack off as a reward for their hard work wouldn't that be nice i mean but slacking off you know even that it doesn't have any value we could be relaxing or doing something that's important to us but no i mean why do we want to slack off exactly you know that's a funny answer i don't like that one personally even though it is it's nice to relax

every now and again adding a card for refactoring code that can be replaced if an emergency comes up now right away that's exactly what we're talking about when we're talking about slack building slack in to a sprint and we'll talk about that in a second last one is creating a burn down chart and a burn up chart together so it's definitely not that one either so when we're planning in a sprint with let's say we can put however many cards six seven cards in um or let's say we can put eight cards in and we

put seven cards for the work that we're doing we can add a card for streamlining and refactoring the code and simplifying and fixing up different your different fixes within our code base to make it easier to work with in the future refactoring is the way that we term that and you know many of you will know that already but for your pmp exam just in case that comes up refactoring the code let's say that has five points against it and the other cards have three five you know between three and five maybe there's a really

big one and all together we can fit all of that in to our iteration then if an emergency comes up then we can just get rid of that slack card and we can spend the time fixing or working on that emergency but just in case if we do have time we have time to refactor the code and that's what we're talking about with building some slack into the sprint so all that to say i think we're going to go with answer c and there it is and all of that you know it's exactly what we've

said so refactoring regularly ensures the code is clean and correct and the refactoring card can be replaced if an emergency comes up uh and yeah so that's really good practice to get into so that was a great question all right let's check out the next one the team are planning their first upcoming sprint on an agile project they have worked with a product owner who has gathered a backlog of features in prioritized order wow this is great so they're working in a great way already we know the features we know the priority of those features

because the product owner is there to tell us and they're working with the team ideally as an agile project manager what must you do to ensure you can plan future sprints correctly all right let's have a look and this is a great scenario like as well this is a great scenario based question so this is the sort of thing that we will see on our pmp exam and agile certified practitioner exam okay will we find the best performer in the team so you know who you can rely on agile is more about the team itself

not about individuals specifically not one person about all of the people so it's definitely not that one find your team's velocity over the next few sprints so you can set a sustainable pace and we've touched on this already over the last couple of videos a sustainable pace is really really important and the way we do that is by finding the team's velocity if we've been able to complete say 40 points over the last five iterations on average then we know in the next iteration we can plan in roughly 40 points and you know that's going

to be okay for our team to complete so we're not going to be overburdening them but we're not going to be you know under utilizing them either so i think that's a really really good one um let's check out the last two set a working group meeting to gain executive buy-in uh that's probably more of your waterfall or you know traditional big organizations trying to get executive buy-in and yes executive buy-in is very important but we want to be inviting them along to our team's ceremonies so that they can understand exactly what we're delivering and

all of that should be open and transparent to anyone who wants to see it creating the project management plan and drawing out the schedule in advance that is your waterfall approach from your project management body of knowledge uh and yeah that's more of a predictive approach to that one so out of all of these to find to ensure you can plan your future sprints correctly we want to do answer b finding the team velocity and and setting a sustainable pace based on that and there it is an agile sprint is based on the team velocity

the team's velocity is the amount of points or cards or features or whatever you choose as a team so it can be different it's completely up to you as long as you agree within the team the team is able to complete on average during a regular sprint you will need to complete at least one sprint to get an idea of the velocity that a team can complete that was great wow great question that one and we've got two to go you're doing fantastically let's see what we've got you are an agile project manager and your

organization is moving away from a waterfall to an agile way of work great that's a that sounds like that's happening more and more these days and you'll see it more and more on your exams and your project management exams too after reading the agile manifesto the functional manager that you're working with mentions individuals and interactions over processes and tools which is one of the agile manifesto you know one of the core parts of the agile manifesto and it and they ask you how you will do it what do you tell them okay well this sounds

pretty good all right what will we do create ceremonies such as the daily stand up iteration planning demos and reviews so demonstrating or sprint reviews and demonstrating the product at the end of the spring retrospectives that encourage team interaction right away i absolutely love that one because the ceremonies in agile so your stamp all of those things stand ups iteration planning sprint reviews and demonstrations retrospectives they're all there to encourage as a team and also bringing in outside people when we need to as well as we've seen like executives or other stakeholders that need to

know about the work that we're doing so i think we could probably just go with answer a straight off the bat but let's look at the others just in case what we do create a process for the team so we're doing individuals and interactions over processes and tools while processes are important we're still focusing on individuals and interactions so we're probably not going to create a process for the team to review that shows the way of work ask the project sponsor to interact with the team by sharing some of their journey that is a nice

thing to do but it's not specifically agile ensuring that the tools have the tools the team have to work with are state-of-the-art software solutions now i mean this is a really big thing you don't actually need state-of-the-art software solutions in order to work in an agile manner agile can be really low technology it could be a whiteboard it could be post-it notes it could be a kanban board drawn on the wall or stuck on with sticky tape with with lanes and columns and and moving cards across physically it doesn't have to be software it doesn't

have to be high tech and i think that's one of the best things about it anyone can get involved anyone can do it all of that to say i still like letter a here so let's go with letter a and there we are many agile practices are based on a collaborative approach which enables fast decisions and ownership of the work one way is to do one way to do this is to co-locate the team so we're all in one place and we can easily communicate with each other but others are the daily stand up team

planning of the of the next iteration and retrospectives to improve the way of work moving forward so all of these are wonderful things and part of why agile is so important all right we're on to the last question you've done great guys here we are you are an experienced functional manager oh in the business who has been asked to lead an agile project team wow okay and this will happen to you if you're a manager in a business or an organization you may have uh your teams coming in working in an agile way of work

and now all of a sudden you have to come up to speed with an agile way of work as well your executive manager is calling it the pro project coach or the scrum master role and so that's what we're moving into as instead of being a functional manager wow this is great this will happen to us you know in the real world you'll see this happen you know that agile leadership might be different to what you're used to but what sort of leadership style will you embody now this should be fairly easy for us because

there's one main leadership style in agile and that is servant leadership where we serve the team we will lead the team by serving the team removing blockers so they can do the work and streamlining the work and coaching the team and growing their skills that's what we're after so let's see what we've got servant leadership well there it is straight away and you can see the others directive leadership we're not directing the team we want them to grow and make decisions collaboratively visionary leadership even though that is nice we're not just focusing on the high

level features agile is actually about getting into the detail as well so that's just not good enough and laissez-faire leadership where you take a hands-off approach and let the team self-organize that might sound okay but still as a leader we actually do want to be involved we don't just want to be completely hands off even as a product owner you still need to give direction to the team and even as a scrum master you still need to guide the team through their ceremonies and everything you can't be hands off so that that's close but it's

definitely still not in and answer a servant leadership where you will lead the team by serving their needs growing their skills and removing blockers so they can get the work done that's what we're after let's see what we got ansaray an agile leader is primarily a servant leader a project coach the focus is on removing blockers for the team helping them problem solve and growing their skills where needed and that is part of what i'm trying to do with you as well help you and serve you by helping you pass your pmp exam and get

up to speed on agile because it's becoming so much more prominent these days and quite frankly i've had a great time doing these questions with you and i hope you've enjoyed yourself as well you're working as an agile project manager in a new project team many project team members are despondent and do not show up for the meetings and ceremonies that you have set okay this is uh this is a worrying sign and an agile team what will you do next um because the reason why agile works is because we have everyone together interacting really

really quickly and frequently so if people aren't showing up you know we're not going to get the results that we actually want so let's see how we can deal with this or you know work through this raise a risk in the risk register around project goals and ask the project sponsor to mitigate the risk look you probably do this in a waterfall project you know people might uh technically you know run a risk meeting you know raise that risk make a big deal out of it and get someone to take action on that risk but

in agile i think would take something different so let's see what else we've got here have a coaching session with the team teaching the what and the why behind agile ceremonies and ensure each meeting has a clear outcome time and agenda i like that one definitely with the team meetings keeping a clear agenda make sure that people understand why we're doing this starting with why you know the simon's the next book start with why uh starting with that first level idea that high level idea it's quite important uh and you know that really can help

so that's a probable one for me cancel all meetings for now and write some documentation for the team on what you'd like them to do no documentation we prefer interacting over documentation as you know from the agile manifesto and we definitely still want the meetings whatever we want to call them ceremonies catch-ups uh we want people to interact it's really important not that one and make the decisions for yourself and dictate the outcomes to the team now while that might be easier uh it's definitely not going to result in in the things that we want

we're probably not going to get the results for the customer that they want or the for the business that we want or even for the team that they want that they want so really out of all of these the best answer that involves all of the people and a collaborative approach is answer b an agile leader focuses on coaching the team removing blockers and ensuring interaction the key agile ceremonies such as stand-ups sprint reviews and retrospectives help support and improve that work and get the answers that people need that was great all right on to

the next question you're an experienced project manager who is used to a directive leadership style where people do exactly as you say now you're working in an agile team where this that style of leadership is not accepted what is one thing you can change to move to a more servant leadership style okay this is a nice knowledge based question let's see what we've got here we can ensure that the executive team makes all the decisions no that's more of a directive leadership style ensure that stakeholders collectively agree on and share decisions yes i like sharing

and even collectively but you know sometimes we don't all have to agree but we do have to collectively in have input into something and problem solve and work through it so that one's a maybe but it's looking pretty good defer to the product owner and the business to make all the decisions no we want to still work through it as a team we need the input from the developers we need the input from the testers we need the input from our business analysts we need the input from the product owner and we need the iteration

manager or the scrum master to be running and you're facilitating those discussions and ceremonies last one find an extremely competent person in the project team and delegate all the decisions to them now that might happen in the real world you'll find favorites you know not you personally but an executive might have a favorite person that they want in the project and sometimes that can work and have its benefits and sometimes it can actually not work you know because it's only one person either way that person ideally will still work in a collaborative manner where we're

ensuring the stakeholders collectively agree and share those decisions so either way i think we're going to go with answer b for this one and there we are agile methods foster team empowerment which increases stakeholders need for effective decision making yes that's right so we're effectively decision making by empowering the team in other words there are two methods to accomplish this collective agreement where the team agrees with the decision or the approach and a shared decision which means the team and the stakeholders arrive at that decision together rather than one party making the project decision so

yeah basically what we're saying here is we're working together as a team we're all having input into the decision and into the into the information that make up the outputs of what we're trying to do and that's a big part of the agile approach all right on to the next question you're working on the requirements for the next iteration and this decision needs to be made by the team the product owner suggests using a show of hands to indicate team members who are or for or against the decision as the agile project manager you object

to this approach why wow this is going to be interesting agile is about software the team should use software to vote for the decision no agile is not necessarily about software we can actually use low-tech tools to manage an agile team it can just be a board on the wall or it could be you know cards moving across lanes made by tape as well on the wall or a whiteboard or anything so it doesn't have to be about high-tech stuff here the decision may not go in your favor so it's best just to do it

yourself even if something even if we don't agree with something a hundred percent as long as everyone has had the right input into the decision then we have a higher chance of it being the right outcome overall sometimes we may be wrong as hard as that is to admit but we have to do what's best overall for our customer not just what's best for ourselves decisions should take time to work through and should not be voted on quickly not true you can still have a fast outcome and a good outcome those two things are not

necessarily against each other so that's also not one for us it has to be the last one then what have we got by making the decisions visible team members may be influenced by others in the team especially executives without the benefit of discussion ah okay now this is perfect and there are a few agile methods that you'll see that can get around this like like the fist of five for example at least with that if we're voting then if someone is unsure about the decision they have a chance to discuss it and give their reasons

and then collaborate with the team and figure out you know which way actually is the best way forward to voice their reasons but this is absolutely correct by everyone making their decisions visible then you can be swayed by others in the team and you may not get the best output so often with you might have the nominal group technique or anonymous voting where people just write down their decision and you can't see who has made that decision then you can't be swayed by your boss and you know that actually can have a really good output

a good a good impact on the decision for your team in other words so let's go with answer d answer d with just a for or against vote there will be no discussion that might produce better or alternative decisions for the issue by making the votes visible team members are more easily influenced by others decisions especially if they report to them outside of the project environment has that ever happened to you you know i know it's happened in in my circumstances you'll see it happen a lot in your career so that was a great question

all right let's go into the next one you're working in a project team who would like to add a few key agile processes to their way of work in their quest to become more agile the project manager mentions performing root cause analysis when problems appear on features focusing on features that bring in the most revenue with pay per use okay wow a few things here and dally stand ups what agile method is she most likely referring to ok root cause analysis focusing on features that bring in the most revenue with pay per use and daily

stand-ups what method are we referring to i don't see pay-per-use in scrum i don't see it in kanban which is more about work-in-progress limits and basically making things visual iteration planning is just something that's part of most all agile techniques uh so that we're you know we're planning for the next iteration coming up um really the the outstanding one is extreme programming and that has a lot of different principles so it could be one of those principles i think we're going to go with enter b and let's see what they've got okay answer b let's

see what the explanation is here because this one was quite tricky for me extreme programming has 14 secondary practices a team can focus on including root cause analysis okay yes that's good and that's a lean technique from way back when you know 100 years ago which is sort of the grandfather or the grandmother of uh of agile techniques as well a lot of them borrowed from lean in the early days focusing on features that bring in the most revenue with pay per use okay right so we're focusing on features that have a high value of

high benefit value okay that makes sense so now um this one has many dollars so we're going to do that one first that's so that's what we're referring to okay i like that one daily stand-ups shrinking teams caused by improvements over time and more okay so it's good to be aware of those have those extra principles in extreme programming even if we're not asked something directly on extreme programming those things will all feed into the principles of agile in general because xp is such a big part of agile that was a really good question to

work through okay let's get into the next one see what we've got and i think we're up to the last one for this section you guys have done great an agile team in your organization would like to include feature driven development practices into their way of work you tell them that feature driven development activities are supported by a core set of software engineering best practices okay so feature driven but also engineering best practices okay this is going to be interesting what practices will the team start with feature releases feature celebrations and feature iterations while that

does roll off the tongue i don't think that's specifically correct developing by feature now working in feature teams and visibility of progress and results i really like this one because what this means is working in featured teams if you think about this and all of the agile methods and principles that we've gone through working in feature teams now the team has a core expertise in this feature and if they're if they're delivering for this particular system or this particular feature you're becoming a real expert in that domain and they they're gradually getting really really really

really good at it and becoming an expert in it in fact and that helps helps get faster and get better over time it's really really great uh so i like that one at the moment finding features developing features testing features uh finding features is just a bit weird and different the other ones are fine but you know not specifically agile and ensuring executive features are allocated and developed um i mean yes you do need some sort of you need ideally to be working with the customer and collaborating with the product owner who prioritizes the features

and tells us what is the highest priority to work on in that way that's probably we're doing that more than just developing what the executives want the product owner might be an executive in the business area but that's another story so that's what that's how that works all of that to say i really think we're going to go with answer b here guys and there it is feature driven development focuses on the core engineering set of best practices such as developing by feature feature teams inspections regular builds the same as extreme programming right so regular

builds where we're continuous integration we're regularly putting that up into one environment and then testing it to see if anything is broken a visibility of progress which is our kanban board you know so all of these different things in the different agile methodologies or or principles or frameworks they all are very similar across all of them aren't they and that's the point that we're trying to get across here uh so all of that to say we're correct you are correct i hope you did great i've certainly enjoyed myself and i hope you have too but

more importantly you are learning so much about agile which is one of the biggest methodologies that you will see in project management today your agile team has been working with feature driven development as a model for their agile way of work for some time now and are ready to add more feature-driven development practices to the things that they do what can we do next as a team ask the product owner for more features in the backlog you know that could be a standard sort of agile thing the product owner definitely owns the backlog or prioritizes

the features that come up they represent the customer that's what we want that's okay hold a retrospective to gather ways to improve i mean yes that's also good retrospective is also quite good um we want to gather ways to improve that's a maybe as well uh incorporate configuration management and individual class ownership that sounds a bit more complex but that's a maybe as well because these are things that as you delve more into feature driven development they're actually a part of feature-driven development so let's put that as a maybe as well and seek send key

representatives to the scrum of scrums across the organization look i mean that's also good so all of these are agile practices so this is really important but the the one that is most concerned with feature driven development is uh incorporating configuration management and individual class ownership and what these are is change management practices so what happens when you change the overall model and with feature-driven development you're looking at a high-level model of what we're delivering and then we're breaking that down into features that will get us to that to that model and then we're breaking

those features down into stories and and then once we have those stories we when when they're delivered into a feature we see if they've worked and we iterate or we change if necessary so that's the change management method and that could be different depending on your team as long as the team has agreed on how we do it and individual class ownership it means that maybe a person or a group of people will own a particular class within the code and that way they're responsible for that and they they can yeah they know everything about

it they become experts in that domain so all of that to say let's go with answer c for now and there it is more feature driven development core engineering practices all right so these are core engineering practices we're delving into the more technical side now which is really cool even though it doesn't have to be technical you know this is where we're going and a big part of agile it can be technical as well configuration management ensuring that changes are known and tracked and individual class ownership where parts of the code are assigned to a

single owner and they become the experts and the owners and responsible for that for that part of the code and domain object modeling is as well so this is a conceptual model of the domain showing both behavior and data and you know that's another part that we can look into you might use a context diagram for example where you've got the system and you know the information's flowing to and from other systems and you know so that's one way to do it there or a sequence diagram you might use many different methods uh well that

was a really good question to kick us off let's get into the next one an executive in your organization approaches you about working in an agile team they've heard about feature driven development and would like to try it as a test and learn in your team what do they mean by this so what do they mean by test and loan or feature driven development let's have a look your team will rely on previous feature designs for your work i'm not sure about that your team features certain abilities and showcases them to other teams i don't

think that one either you know it certainly has the words in it but it's not necessarily about agile or feature driven development your team enjoys the feature of working with agile and agile organization not necessarily as well again it has the word in it but probably not necessarily for feature-driven development and last your team will trial developing an overall model here we go then planning designing and building by those features which is exactly feature driven development and so we we have the overall view the overall model of what we're trying to do or accomplish or

create and then we have features that you know we're designed by those features and then we create you know individual story cards to exactly as we saw before and then when we release something we get feedback on it and then we we iterate so we change if necessary and that's the benefit behind developing by feature and having featured teams you know who are experts in those particular features or those domains as well let's go with answer d answer d agile feature driven development starts with an overall model then plans designs and builds by those features

once a feature is complete the process can begin again complete with any learning from the previous feature so we've released it customers have given us a little bit of feedback and now we might need to adjust our approach and that's the benefit of feature driven development that was another good one all right let's get keep going for kanban okay moving on or flow based agile iterations follow the number of story cards in the work in progress limit or wip we call it sometimes shown on the visual or virtual board which is our kanban board so

it's a columns where we move uh the features or stories or tasks across the board from from the backlog all the way to done and that's just a good way to keep track of everything so the team pulls cards from the backlog column on the kanban board based on their capacity so if someone has extra capacity they can pull maybe extra cards start working on those these story cards provide an increment of value yes exactly and they are a primary driver of executive behavior primary measure of progress yes i like that primary way to pay

for the cost of an agile team not necessarily primary enablement enabler of people's engagement i mean look that's a tricky one because progress actually has been shown like there have been studies done that when people are making a have a sense of progress that is when they feel the most engaged so it actually could be that one but kanban by itself as a method is a way a primary way of showing the progress is actually showing and measuring that progress so let's go with answer b for now answer b the key to kanban is making

progress visible progress naturally improves team engagement oh there you go no one likes being stuck and blockers are clear for people to see so we can see it on the board oh it's been on the board for two weeks okay maybe we need to do something about that swarm around the problem see if we can fix it and we can also assist with those problems that was another good question wow these are really good today so we've got kanban let's move on to the next one and see how we go you have just come on

board an agile team and a decision needs to be made about product requirements oh this is good the scrum master asks the team to show either thumbs up thumbs down or sideways okay what does a thumb sideways mean that the team member doesn't mind about the decision either way i mean that sounds right but that's not right and we'll see why in a second the power behind agile is interactions remember it's discussion and getting answers quickly not waiting so this is why this is really important the team member has a concern or conflict that needs

further discussion and this is the most powerful part behind this actual this method that we're using here very simple method deceptively simple but also extremely powerful the team member defers to the executive sponsor to decide that will happen a lot um even just by default just because executives sometimes have the loudest voice in the room or even the most power in the room and again that's why having discussion and having open discussion is so important because someone might have information about this that the executive does not know about the decision is outside the team members

expertise and they choose not to vote unfortunately in an agile team everyone has to vote and you know i mean we're not going to force anyone but we want everyone to have a voice for that very reason that there is information that people might have or know or even questions they might ask that might bring up you know something that we need to think about or talk about but for this one we're going to go with answer b and there it is when voting in an agile team members who vote with a thumb sideways have

a concern or conflict with the decision and would like to discuss it further and it's the same with the fist of five so you know if you've got people will vote on something and say how confident are they in this and if they give a three or below then basically that gives them the chance to discuss that item or discuss their concerns really important all right we're getting through it next question you're at the beginning of a new iteration and about to plan and decide what gets worked on in the upcoming sprint oh these are

great questions today you decide to invite all project stakeholders to the planning meeting to decide what to work on next why is it important that all stakeholders are involved in decision making and now this is a great one currently you know i mean you will face this in your job where people don't want everyone to be involved in decision making um you know these are the remnants of the old ways of doing projects but you know what then you're missing out on all of the good stuff but let's see why it's important as well so

you can keep on an eye on what they're doing this is great so we invite those stakeholders to keep an eye on them just in case who knows what sneaky things they might be doing uh look i mean that i mean that might be a thing but it's not the agile thing i guess so let's not go with that for now so business representatives can report back to their managers on the project uh i mean that will help um but maybe that's not the 100 thing either so the team feels important and with lots of

stakeholders present uh i mean that's definitely not the one uh must be the last one so the project stakeholders don't reject a decision that wasn't theirs oh and this is the power behind keeping everyone involved actually actually involved in decisions and inviting them keeping things open and transparent because then those stakeholders don't reject a decision that wasn't theirs because they weren't part of it if they're not part of it then they can say oh look i don't like it and look studies have shown again that people are more likely to reject an idea that that

they don't have any ownership in or they don't have any um contribution to so you know it's just a normal psychology psychological thing within people every day and you will probably have found this in your job already if you haven't you certainly will all of that to say let's go with answer d for now there it is giving ownership in decisions to the team and stakeholders is one way to gain their buy-in if stakeholders are involved in decision-making they'll be more committed to any decision made into the project itself as well so important and that's

a that's another really really good question guys uh all right i think we've got five to go let's get to it you're doing great you're an agile team and you notice that it's different to other project areas that you have worked on that's right it will be very different and sometimes you know there's a fuzzy middle we have to work through and get through all of this uh stuff to get to the good stuff in an agile team that transparency um you know that that fast flow of of information and of work through the team

the project manager tells you there are certain ways to ensure that stakeholders stay engaged what is he talking about that's a good question okay removing any team member who is not engaged in the project look i mean i mean you may come across this in your career certainly it's not the first choice absolutely certainly there are times when uh people just don't fit and you will find this it will happen in your career but that's not the first choice in an agile team we want people to come along for the journey if possible so giving

any extra work to the better engaged team members no we want everyone to be involved as we've seen and everyone to have an opinion and to be involved in the work ensuring visibility transparency and progress of the work through charts and information in the common team area yes so this is a really great way to keep people involved and as they're involved as we've seen they're engaged or more engaged so all that transparency of the information it's right there people can see it at the drop of a hat they can walk through the team area

and see how the team is going and you know what sometimes it's not going well but then everyone sees it and we can say look maybe we need to help and do something about it so that is why that's so important last one offering a possible promotion to the most engaged team member at the end of the project look i mean this will happen in ebbs and flows some people will get promoted some people will stay where they are there are very different reasons you know all across your career for seeing these things happen but

that one is not specifically part of an agile team so let's go with answer c and there it is visibility visible progress helps maintain obtain team engagement and is facilitated through the use of the information radiator which is that team area the kanban board the burn down chart the product backlog seeing that and being for that being clearly visible to everyone and that's just a great way to keep people engaged great stuff guys last four questions doing great you've been identified as a stakeholder on an agile software development team as you join the stand-up the

team stand up you're surprised that there are only eight people on the team and no more after all the deliverable is quite large oh no if it's large we must need heaps of people right actually not right so let's see why why is the team so small the agile methodology is being trialled as a cross-discipline self-forming team uh i mean look that will happen and that's sort of a thing you know we want our agile teams to be self-forming we want them to have that domain knowledge to actually care about the product that we're developing

this one's a maybe i'm not sure about this so one person was selected for each role necessary and no more not necessarily true we might need multiple developers for example we might need multiple testers even even multiple business analysts but probably only one product owner if we can possibly help it uh not that one agile methods recommend the delivery team to be 12 or fewer members yes to this one so this is an actual recommendation by agile and the reason why this is a recommendation by agile is the communication channels let me tell you why

there's an actual formula for this i can't remember it off the top of my head oh maybe i can but the more people you have the more ways there are to communicate the more channels there are of communication if you have two people it's just back and forward easy if you have three people now you have this way this way and then this one and then and then if you've got four then it actually starts to increase uh almost exponentially so it's uh it's not just four methods of communication because now you know each people

each person will be communicating with each other person so it's it's more like you know a 10 10 ish or eight or seven or eight actual communication channels there and then more and more and more and more and more i think the actual uh mathematics behind it is like say if we've got 12 it's like 12 multiplied by 12 minus 1. so 12 multiplied by 11. i think it's something like that someone please correct me i go and check the actual mathematics behind it um it's very simple to find out but you know as you

can see it's not just 12 channels of communication it's something like what what is that like 130 or something similar uh different ways and methods by the water cooler by email you know this person talking to that person so that increases the complexity anyway enough of me waffling on but that's really important and let's go with answer c agile methods recommend a team of 12 or fewer typically between three or nine this keeps the communication channels small and ensures information travels quickly for the team to do their work and that's the important part behind it

well done guys keep going we've got a couple to go question next question oh and it's another good one too this is such a good session i'm glad you came along for this one as the lead on agile project you have carefully cultivated a team of t-shaped people and we have been through this before in agile questions but what is a t-shaped person they have a broad range of interests and and skills so they might have a bit of development they might have a bit of design they might have a bit of requirements gathering they

might have a little bit of you know testing or automation or something similar and yet at the same time they have one deep specialty one extreme specialty that they're really really very good at and that's their core function so that t-shaped team member is such an asset if you can get those team-shaped team members and they're happy to work with you and they're engaged and they're they're good people you know this is the most valuable thing on the planet and it will help you get your work done anyway all of that let's go let's see

what we've got here a person that has flat knowledge up top and long knowledge down the bottom okay not that one a person with a wide range of general skills and one deep skill or knowledge area well as we've seen that's the one what else have we got here just so we know what to look out for a person with a wide range of leadership skills as everyone should lead on an agile team yes we do want everyone to lead on an agile team but that's not for our t-shaped people you know that's not the

definition of it at this stage a person that has more contacts in the management layers and a few contacts in the team layer again not that one so we know that we're going for answer b and there it is that a generalizing specialist is a person that has one deep knowledge area or skill and a wide range of general interests or skills an agile team is generally made up is ideally made up of these generalizing specialists who can do more than one thing but also do their core role well well done guys last two questions

you're doing great in 2001 a group of individuals representing the most widely used lightweight software development methodologies agreed on a common set of values and principles which became known as the agile manifesto this is uh this sentence you'll see this so often um because this is where agile came from you know all of these the the core individuals came coming together and agreeing on that high level manifesto that has become agile in that manifesto they valued what do they value individuals and interactions over processes and tools definitely that one executive reporting over bottom-up reporting scrum

masters over project managers yeah i mean the name doesn't matter but the function and what we do actually matters so doing the work overviewing the work that sounds nice but that's not part of our agile manifesto so let's go with answer a here nice and easy there it is made up of four core values one of which is valuing individuals and interactions over processes and tools well done guys i think we'll have a few more of these over our next couple of videos too last question well done you're doing amazing work keep going here we

go you're planning the next iteration for your agile team as the agile lead and the team is going to select user stories from the prioritized release backlog elaborate those user stories and estimate the work needed for each user story the number of stories selected is based on and this question is awesome scenario based question you're really going to have to do this in an agile team so important what the scrum master says as they know best nope scrum master facilitates discussion within the team the team's velocity which is the rate at which a team can

complete work yes the number of stories yes that's exactly it so if we have 20 stories in the backlog but we know that we can get five stories done in an iteration then we're going to take five stories and we're going to put them and plan them for the upcoming iteration that is our velocity of work how fast we can do the work and that's just based on the average of what we've completed over past iterations uh feature driven development model no what the team wants to work on to ensure individuals work within their strengths

also not necessarily we do want people to be engaged in what they're doing but the product owner decides the priorities because they represent the customer and we select how much work we can do based on our velocity let's go then to b and there it is the team's velocity is the amount of work they complete on average in a given iteration now this can be measured in different ways in points in cards in features in stories in t-shirt sizings or any other method that works for the team as long as the team agrees together on

that method the number of points in a sprint however is based on the average velocity of points from previous iterations and we made it you made it you've done amazing work and you're preparing yourself so well and also learning a little a little bit about this wonderful thing called agile that you will see in your career over the next 50 years it's only going to get bigger and you're doing a great job your team is standing around aboard with cards on it okay this is good start each person is answering these questions in a round

robin fashion what did i complete since last time what am i planning to complete between now and next time so between today and tomorrow is anything blocking me what is the team doing now this is the core practice in an agile team we should all know this one very simple start it's not a luncheon loan it's not a working group meeting you'll see these happen still but it's not that it's not a retrospective although that's still important it's the daily stand-up where we meet every day for around 15 minutes hopefully no more with our small

team of of fewer than 12 people hopefully to keep the communication channels small let's go with ncc here it is the daily stand up in an agile team asks in a round robin fashion all of those questions what did i do what do i plan to do and is anything blocking me and we talk to the cards in flight on a kanban board usually so from in in progress from to do in progress to done and that's how we see how things are tracking we make it visual and that's part of the beauty of it

as well all right that was a nice simple one to start let's see what we've got next there are multiple project life cycles you can choose from depending on the type of project environment deliverable and stakeholders you're working on a project that requires features of an overall product to be delivered on a regular basis what sort of project life cycle will you choose to work with oh this is wow this is good okay and and this is really important because look agile is fantastic but it doesn't suit every situation and we need to be aware

of the circumstances where waterfall might actually work better or simply incremental might work better or iterative where we're delivering in one big bang still but we're iterating and improving before we get there by using feedback so let's see what we've got here we're releasing features on a regular basis sounds like we're releasing in increments according to the project management institute or it could be agile itself so it's not waterfall because that's one big bang could be agile uh could be iterative does one big bang as well and incremental um is where we're delivering increments or

features so if we're going to be strict with this let's go with enter d and see how we go okay luckily enough while others may meet the criteria of regularly delivered features like agile itself because agile is a combination of iterative where we're improving based on feedback and incremental where we're delivering increments or features so it's a combination of those two things an iterative project lifecycle specifically delivers those features in increments of value over the life cycle of a project okay that's really good to know and a great life cycle question too to kick us

off on this question journey doing great let's see how we go on the next one you're working as an agile project manager in a new team that's not familiar with agile the executives are not as comfortable using agile in full just yet you suggest using a hybrid approach to begin with to help the organization meet their goals what does this mean what does a hybrid approach mean is it a tailored combination of predictive iterative incremental and agile approaches straight off the bat yes yes it is a hybrid approach to life cycles and how we're going

to run our project is a combination of all of those things just like we know that agile is a combination of of increments and iterating and improving and gathering feedback we also know that if we're using a hybrid approach we might actually be using some parts of waterfall in there as well we might have an overall project plan it might be you know a release train of features or larger features where we're needing that that project plan and some of those waterfall approaches to make it an overall hybrid approach so i really like that one

what else have we got using a project management plan to plan the project while delivering features well i mean look that's actually not bad either so that's like that sort of describes what we were just saying a combination of reactive and proactive no and using agile only when it's needed such as in a software development team it's not just in software development that we can use agile the principles apply to every project management scenario where we need to deliver in features and get feedback on our work so for this one if we're going again with

a strict definition let's go with answer a and see how we go all right even though b was quite good as well a hybrid project life cycle approach incorporates parts of predictive iterative incremental and agile it allows the project manager to tailor the approach to suit the situation and that's part of the point so while answer b we just had a few different things but overall we want to be able to take lots of different pieces as they suit our situation and that's why answer a is the best one there all right that was a

little bit tricky good job guys keep going you know this is a little bit of fun too we're getting some varied uh ideas here the agile team leader works through servant leadership to the team and has built a safe environment for disagreement oh and i cannot say enough how important that is it is so important um you know can we be open can we actually challenge the ideas in a safe way how has this empowered the team to move forward without obstacles okay the team is able to create a list of reasons why tasks cannot

be completed look people will come up with reasons why things can't be completed but we don't want to focus on the reasons we want to focus on how we're going to problem solve a way forward that's our approach the team has no conflict and they get along so well no also no we actually want a little bit of safe conflict we want to make it safe to raise conflict in a team because that is you know the messy part of figuring out and problem solving is actually really really important that's part of where the magic

is but we want to make it safe for people to do so so don't reprimand people when when they do raise these things really really important the team leader takes responsibility for all decisions no again uh you know servant leadership is growing our team removing blockers for the team but letting the team do the work they came to do lastly the team is encouraged to participate in discussion and even disagreement yes disagreement doesn't have to be a bad thing i can disagree with you and i can still love you and we can still be friends

and good people but as long as we're disagreeing in the right way and looking at the problem itself not at the person looking at the process how do we help the process while still understanding that people in themselves are trying to do the best they can and are doing the best they can with what they've got at the time you know this is just it's hard it's hard to do in real life but it is really powerful when you get it right and in order to make better decisions i love that one let's go with

ncd constructive discussion and disagreement is encouraged to ensure risks and alternative ideas are found it is this is only maintainable in a team with high psychological safety so can i disagree with you and not be reprimanded for it yeah that's part of the the approach that's why it's really important in an agile team wow that was a good question i had a lot of fun with that one all right let's see what we've got next new projects go through the tuckman model of forming storming norming and performing and oh boy if you've been on any

project even one or if you've been on 10 or if you've been on 20 you know you will have seen this time and time again because projects are constantly forming and going through these stages as they're trying to complete the work that's why project life is so hard and also that's why having a framework like the pmbok guide and the project management body of knowledge and agile in this framework as well is so powerful and will help you in your career it certainly has helped me anyway enough of me waffling on you've just taken the

lead of this new project with a newly formed team and you're surprised to find little conflict and that the forming stage has gone so quickly how did that happen which of the following might be the reason the team members have worked together on previous projects and are following the same agile ceremonies and methods this is a really big one if the team has worked together already they have already been through a lot of this forming and storming and norming stage and potentially are performing together already and also having used all of the same ceremonies and

being and working together in the same way then they're already doing a lot of the things that that you need to work through uh when a project team first forms so they're already at the good stage i think this is a good one you've made all the project decisions yourself so they don't have to worry no that's not the agile way of work as we've seen the team is in line for a promotion so they really want to get along not that one today and the team members really care about the product being delivered while

this is really important the most important part is if we can get people who have worked together previously that will help skip some of the stages of forming storming and going into norming and performing let's go with answer a there it is if it's important to be aware of the tuckman model when we're starting a new product a project because this will affect you whether you're aware of it or not so now that we know about it we have another tool in our tool chest right so this is great using the existing agile methodology and

ceremonies can help smooth that process of coming together as can having a team who's already worked together on projects before so that's a really good way to do it if you ever want to shortcut that process that's how you can help and that's how you can do it all right wow these questions are great today okay let's check out the last five i think we're up to the last five you're doing great and we're going through 10 you know just so that you know this is going to really help you prepare for your exam what

have we got here you're a project manager of a new agile project you are you ask questions of your team to elicit their needs and help them problem solve issues as they arise wow and this sounds like the scrum master doesn't it but the scrum master can also be called different things it doesn't have to be scrum it can be many different names but they perform the same servant leadership role let's see what we've got what role are we fulfilling in an agile team project director we don't direct we don't tell people ideally we facilitate

discussion project coach yes yes we're coaching the team we're you you're getting their feedback we're helping them along their journey helping growing them and removing blockers to their goals project support no not today and project executive even though there might be a sponsor or an executive that's not what we're doing as an agile coach or an agile lead or an agile you know scrum master basically that role helps grow the team and remove blockers and that's that's why you'll find that the team grows better in an agile team than it does just being dictated to

in another project team so let's go with answer a b sorry the project lead can be called many things in agile but usually centers around servant leadership and the project coach role who helps grow the team and remove blockers to their work well done guys all right last three questions you're doing great you're an agile project manager leading a new software project during the last retrospective there was very little engagement and feedback and the teams seem to be losing interest in their work what will you do to improve the situation hold another retrospective to try

and extract more information that's one way we could do it align the project goals to each team member's personal goals wow that's really deep so that's deep into as a leadership model you know really delving into each team member and finding out what their needs are this is really serving the team that's a pretty good one quite deep though yeah very deep into it hold a vote on whether to continue the project or not sometimes the project may just have to continue so we would we need to figure out best ways of working and to

try and keep going if possible and get executive management involved so team members can raise their engagement you know that's probably not going to do it but for them to be involved in the decisions for them to have transparency in their work and for the work to be aligned to their goals is probably going to help us so based on that even though we could hold a retrospective aligning to a person's goals is the most powerful here to help improve the situation let's go with answer b if a previous retrospective did not elicit the information

then holding another one would be doing the same thing but expecting a different result and that's really important to note and we can be aware of that in our own job and our own career finding out each team members strengths and helping them to do more of that work helps engagement as does aligning their goals to the goals of the project when these things are aligned people naturally work harder and care more wow these are really getting deep now these are great questions good leadership for any type of leadership but specifically for our agile journey

all right next question last couple you're working as a project manager in a team that is moving to an agile way of work you're pre you've previously engaged in a team in a single team weekly meeting a working group meeting with email as the primary communication doesn't sound very agile when you know about the things that we've learned in the last couple of videos does it so what changes will you make in the new agile team you can probably already guess but face-to-face communication or close communication will probably be a part of this ensure that

reports are created weekly for executive management too slow and reports we prefer face-to-face communication set up a teleconference with different parts of your project team if we're not in the same place this could be okay but there might be a better option here co-locate the team where possible and focus on frequent face-to-face communication there we go that's the one we're probably looking for on this one we'll almost lock that in and have frequent one-on-ones with your project team to get their point of view in private uh i mean this can help but really what we

want is to be discussing and collaborating as a team where we possibly can so for this one i love the best answer let's go with answer c agile focuses on individuals and interaction co-loading co-locating the team to gain information by osmosis oh now this is a good one with face-to-face discussions being the recommended method of communication what is osmosis this is where where we're like getting information just from the information that's happening around us so if we're working in a co-located space everyone's in the same space together you might overhear a discussion with with anne

and with you know with leslie or or whoever cheryl whoever it is all these people will be talking together and you'll say oh i actually needed some of that for the piece of code that i'm working on or for the feature that i'm delivering or you know or that i'm helping get the requirements for or all of these things this is uh getting this information by osmosis it's just sort of seeping into our brain because it's around us incidentally this is why it's so important who we spend our time with as people even in our

jobs um and you know or at home with our circle of friends because all of that information is constantly seeping into our brain by osmosis we may not be learning it particularly but it's still around us and it's actually affecting the way that we view the world and what we can do particularly in our project anyway that's me waffling on but you may need to know that for the exam gathering that information by osmosis all right last two questions well done guys kanban translates to visual or visual sign or card in japanese and oh it's

a form of visual management taken from lean manufacturing the toyota production system and it's used for monitoring work in progress and enabling pull and flow 100 yes so we're pulling the cards only when we're ready based on the work in progress on our kanban board so we can't take too much on but when when this card's moved all the way to done then we can take our next card because now we can see that we we we've seen the work in progress limit uh so there's not too much on the board now now we've got

room to take more information on uh answer a is the best one here that i can see so far the team enabling executive reporting no work velocity uh that's more scrum story card elaboration that's with our business analysts or our test and our testers developers and product owners and the scrum master and enabling team participation not particularly with kanban it's really more about pull and flow so pulling information or tasks to work on when we're ready and the flow of those tasks through our kanban board so can we remove those blockers can we keep them

flowing through our kanban board let's go with answer a there it is kanban is a framework from the toyota production system utilized in software development and in knowledge work it focuses on the kanban board and it shows and limits the current work in progress really powerful kanban is such a great addition to agile and it has its roots in the lean and toyo production system from more than 100 years of use in manufacturing really powerful last question you've done it you're doing so great here we are can we figure this one out looks like another

kanban question so it shouldn't be too hard you're working with an agile team who use kanban to manage the flow of work through the team the scrum master or agile lead mentions the concept of pull which helps the team manage the work what does this mean and it's a good thing because we just spoke about this that was good timing wasn't it the team gathers around the team velocity board ah there's no velocity board really each morning to ensure the work is being done let's not go with that one the team pulls work only when

they are ready yes instead of the work in progress constantly building up so we don't have all of these things in progress we try and do this one we try and remove the blocker and then move it across and keep moving the flow of work through the team the team works with a pull and push approach between developers and testers even though it has the right words in there that's not the idea behind paul and the scrum master tells the team to pull the appropriate levers that enable the right features to be developed again you

know similar words in there but that's not what we're going for answer b is the one for us and there it is kanban allows team members to pull new work onto the kanban board when they are ready it limits the amount of work on that board and it encourages an optimal flow of work because we can see if something is blocked and we can swarm around that problem and try and fix it as much as possible you guys have done it that's 10 questions to start your day or to finish your day or just to

prepare for your exam or even to have a bit of fun within your team i've had an absolute blast spending this time with you and i hope you've enjoyed yourself too you're walking through the next feature with the product owner in an agile team he is new to agile and unsure of what kanban really is he lists a few things for you to check which of the below is not one of the core properties of kanban alright let's check it out visualize the workflow and limit the work in progress yes that's what we want to

do on our kanban board we only want to take on so much and then if something is blocked we want to swarm around that and fix it and unblock it so that we can keep that work flowing through our team manage flow that's flow flowing through the team and enabling pull so we're only pulling new work onto the board when there's room because we're limiting that work in progress i like that one too implement feedback loops and improve collaboratively a hundred percent uh i think uh although is that more scrum i mean it definitely is

agile overall let's see what the last one is follow procedures and don't deviate from the plan okay that one's definitely not the core property of kanban so it's good that we're improving collaboratively and using feedback loops as well really part of the agile approach gathering that feedback trying to improve and really improving constantly so we're getting better all the time the incorrect answer being the correct answer is answer d kanban is a method borrowed from the toyota production system or lean it focuses on limiting the work in progress so the work is focused uh and

ensures feedback loops are in place making the work visible so blockages are clear exactly what we were just talking about and that's a really powerful part of agile that you will come across all right that was a good one to start with you're working on an agility on agile project as an agile project manager you have been working using kanban to monitor the work and keep it visible for all to see what is not a defining principle of kanban oh good we get to look at more so now we can really get a good view

of kanban over these first two questions okay start with the current state and respect the current process hmm i wonder maybe agree to pursue incremental evolutionary change definitely we're constantly wanting feedback lead at all levels yes definitely leading at all levels directive leadership over wasteful team product participation directive leadership as we know that's not the way in agile team it's servant leadership where we're serving the team by growing the team and removing blockers for them to do their work for us all to do our work so the incorrect answer being the correct answer here let's

go with answer d kanban like agile itself encourages team participation over directive leadership it keeps the work visible and makes blockers clear it makes them stand out we actually want to see problems so that we can swarm around them and fix them you know we're not afraid of problems we don't want to hide them we want them to be out in the open and it helps everyone assist in removing them and keep that work flowing through the team that's part of the power and that's part of why agile works so well all right great work

guys well we're really getting through these ones all right oh and it's it's where agile came from i love these questions so in 2001 a group of individuals representing the most widely used lightweight software development methodologies agreed on a common set of practices values and principles which became known as the agile manifesto that we all know and love this is where it all started from back in 2001 which of the following is one of the agile manifestos core values all right directive leading over servant leadership no we want servant leadership as we said working software

over comprehensive documentation oh yes a hundred percent we're releasing features that can be used that the customer can see feel and touch we don't want to write a manual about it we actually want to release a working feature instead or a part of the software this is part of the power so making useful large useful features over making small increments no we want to be releasing small increments so not that one and pushing work through quickly over limiting work in progress as we've seen with our kanban questions we do want to limit the work in

progress and we want to work on small pieces of work not big ones you know all of the small pieces eventually become a big feature or a big piece of work so the the best answer here is working software over comprehensive documentation answer b and that's part of the agile manifesto so there are four core value statements one of which is that one that we've said and that's great that's another great start to our question set wow all right let's see what we've got next you've joined a new project team okay this sounds like a

scenario based question which is going to be awesome um you'll see this sort of thing on your exam now we're moving to an agile way of work part of this is co-locating the team to gain the benefit of osmotic communication your project sponsor asks what this means what do you tell them and we've covered this in a couple of other videos do you remember or have you seen this before osmotic communication the team is able to meet more frequently no i mean yes that helps but that's not the definition of osmosis it's easier to hand

off work to someone if it meets their strengths i don't think we're going to go with that one at all we will actually want to reduce handoffs if we're being honest so we want something to stay with someone because as soon as we hand it off to someone else they have to take time to get up to speed on it multitasking has been shown to actually reduce the efficiency because we're having to get up to speed on each new section that we're starting with that we're multitasking on so anyway that's a bit of information behind

that one it's written it's a written process made available to everyone in the team for transparency no again we want interactions over processes as part of agile don't we and lastly the team will overhear conversations and information in the common area that will help them solve future problems this is the exact definition and this is why co-locating is really powerful because we'll just pick up information by osmosis it will be happening around us we'll overhear that information and that will help us solve future problems so let's go with answer d and there it is it's

the accidental overhearing of background information that may later end up being important and that's part of the benefit to co-locating in an agile team well done guys all right next question you're working in an agile team and you are not co-located alright this is really good they are in various locations around the country as the agile lead how will you get the benefit of agile without a co-located team all right can we utilize group messaging yes daily teleconference stand-ups yes electronic kanban and backlog yes yeah all of those things and these are the agile principles

or tools and processes and practices without being you know in in the one place it still can be done it's not as good but it definitely can be done ask the organization to relocate the team i mean that would be ideal but it's not always feasible is it so it's not always possible so that's a maybe hire or find new team members from within the organization who are in the same place now i mean you may not have all of the skills that you need in the one place they you might need to go outside

the organization you might need to go outside the country you may need to go outside your city either way we would be limiting ourselves if we only uh sometimes if we only did it in the one place so that's something to consider that's a maybe as well and remove all meetings so people can focus on their work without distraction no so i think we're going to try and roll with this and try and help and let's go with answer a because we're using these tools and practices to help communication even though we're not in the

same place answer a there it is it may not be feasible to move entire teams or even to hire new ones utilizing the many electronic options so your team can still get the benefit of frequent contact is the most cost effective approach that's something good to be aware of all right that was a good question too now we've only got a couple to go so you're doing so great let's get into it you're leading an agile team that has team members in various locations oh wow this is great so this is a really good core

piece of information that we can get a lot of knowledge on during these question sets you've arranged daily stand-ups via phone with electronic kanban and backlogs and the team but the team is not able to meet face-to-face what else will you do to help the team to increase the team working together and getting to know each other all right have a team board with their backgrounds and pictures that can help that's one way swap roles throughout the team so each team member gets a feel for what others do we don't really want to be swapping

roles we might want to be helping other people or teaming up let's see what else we've got pair up team members to work on tasks oh that's exactly what we're saying and rotate those pairs for each feature so now we've got people pairing up you know ann and jacob for example and then you know two other people and then they can swap around so people are getting to know each other and they're helping each other so i think that's a really good one and pair programming in general is a is a concept from agile from

extreme programming where we're actually pairing up one person will code one person will check but it could be for any role really it doesn't just have to be for developing or programming lastly have a virtual lunch and learn where team members share something about themselves again pretty good but from an agile perspective let's team up and start working together even though we're not in the same place answer c and there it is pair programming is a common technique in agile and can be used for most tasks pairing up team members on a task or iteration

gives them the opportunity to talk and work with each other one on one that was really good all right let's go into the next question you're doing great you are showing up to the project sponsor around the team area for your agile project and you see the burn down chart next to the team kanban board the project sponsor asks what the chart tells you what will you say um so what the burn down chart tells us it shows how many team members are moving on and off the project no it's the velocity or the flow

of work through the team from what we promised to do to what was completed at the end of the iteration so it shows the remaining tasks versus what was planned potentially it shows the automated tests run as part of continuous integration no it shows the return on investment for delivery features no so the one that matches up with that description the best is answer b remaining tasks that were planned for a given iteration uh let's go with answer b great a burn down chart is a line chart showing the iteration tasks completed versus what was

planned over the iteration the same idea can be used for features over the life of life of a project or even risks within the project itself and can be measured in any way you choose by hours tasks cards or stories completed as long as the team agrees on that way of work well done guys all right let's get into the next question we're nearly up to 10. we're going to be doing 10 questions great way to prepare for your exam so let's see what we've got you're working through the feature backlog with the functional manager

of the organization who is also the product owner for your agile team and you will see this happen quite a lot there they have a normal day job but yes they also are the product owner because they have that expertise of the business area that we're delivering value to so this is quite good they ask about the velocity chart that is hanging in the team area what do you tell them that this is it's the number of points tasks or features completed by the team in each iteration uh yes i like that one already so

that's probably a good one the number of team members working on the agile project no not that one that's not our velocity it's how much work we can do on average that we've seen over the last few iterations how fast each team member completes their work each day this is more of a team thing it's not just for one team member the speed with which the project budget is being used up we might feed this into the project budget but but it's not specifically about the team budget and usually with our velocity chart we'll have

it could be a bar chart and we'll have what was planned and what was actually done for each iteration so we might plan this much maybe we did this much so it can be a simple bar chart very very simple and now we can see on average how much we're completing and then we can plan try and plan around that we can plan to that average each iteration that's how we use the velocity chart all right answer a the team velocity is the amount of work a team can complete in a given iteration whether it's

measured by points hours story cards tasks or the features themselves or anything else you agree upon as a team the velocity chart therefore shows the number of whatever unit of measure you choose per iteration very powerful stuff and really essential for our iteration planning for planning the next iteration we know how much we can complete let's not overburden our team and let's put it around that average well done guys last two questions you're doing great in 2001 oh good it's another where agile came from i love these okay these are nice ones to get into

as well aren't they a group of individuals representing the most widely used lightweight software development methodologies agreed on a common set of values and principles which became known as our agile manifesto which of the following is one of the manifesto's core values let's have a look developer negotiation no we want to avoid negotiation we want to respond to change so product owner interaction over scrum master delegation that's not what we're looking for as well customer collaboration over contract negotiation and that's exactly what we're saying we're wanting to collaborate with our customer who we're delivering the

value to we want if they say look you know look or if we need a discussion around we need some change here then we need to respond to that change instead of writing into a contract that we're never going to change anything and then just delivering something that actually doesn't fit the customer now that they've seen it and they can actually use it and now they have that feedback so this is so important and it's part of the power of working in an agile methodology or an agile way as well getting things right over getting

the right things both of these are important and sometimes we need to adjust and that's the point we want to collaborate instead of locking things down and we want to change where we need to and where we can let's go with answer c the agile manifesto is made up of four core values one of which is customer collaboration over contract negotiation and when we've made it to the last question well done here it is let's see what we've got oh and it's an a life cycle question really powerful because agile won't fit every situation you

know we can love agile and yes it's good but sometimes we need to be aware that we need to use a different methodology because that actually might fit better so let's see what we've got here you're working with your project team in a way that ensures you analyze the requirements then design build and test for those requirements repeating them until the product is correct and adjusting your product or approach as necessary before releasing in one large feature which project life cycle are you using so the the trick here is we're responding to change iterating but

we're still only releasing in one large feature waterfall actually just plans up front and doesn't change but an iterative approach has one release but we're iterating towards that release so we're gathering feedback doing prototypes um and adjusting as we need to so for this one it's not predictive not agile not even incremental it is our iterative approach answer d the iterative project lifecycle analyzes designs tests builds and repeats these activities until it is correct then delivers in one release incremental delivers small increments of value for example features that we're releasing and agile is a combination

of iterative and incremental predictive does one release with no feedback usually and we've made it to our 10 questions you've made it through the 10 questions you're preparing for your exam and i truly believe that you will pass your exam because you're working so hard and learning so much about agile and all the different methods in project management large-scale scrum or less aims to organize several development teams toward a common goal by extending the scrum method across teams so you know we all know scrum we've got our daily stand-ups and we've got our iteration planning

and we've got our retrospectives and all the other ceremonies but now we're doing that across multiple teams across the organization so what is not one of the similarities between large scale scrum and normal scrum okay this is going to be good let's check it out okay and let's look at the normal scrum methodology maybe that will give us a few tips here so one single product backlog that's probably right we we want that in normal scrum one definition of done for all teams that could be correct as well we definitely want a definition of done

in scrum uh valuing individuals over results ah that's a it's a little bit strange that one because we want both really don't we we want individuals yes 100 but we also want results if we're not getting results then why are we doing this in the first place this one's a bit of an iffy one for me let's see what the last one's like uh one potentially shippable product increment at the end of each sprint and that is so powerful that's a hundred percent yes for that one so the only iffy one here is c and

only because we want both really we want results and uh valuing our individuals as well let's go with answer c there it is large scale scrum has many similarities to normal scrum extended across teams they include one single product backlog one definition of done for all teams complete cross-functional teams oh so that's good that's where we've got our t-shaped people remember so with a wide range of expertise but one deep expertise these are the generalizing specialists in our team one product owner and one potentially shippable product increment at the end of each sprint and if

you're continually shipping small increments no matter how small but as long as they are usable you know that is the most powerful thing and i've seen it work so many times in the real world that's why this why agile actually truly works it's not just a methodology that was a good one to start with all right let's get into the next one and it's another one on less which is even better so this is great these are our auxiliary frameworks our scaling frameworks about agile which are still extremely important and important to use when you

put this into an organization when you're using it across multiple projects so it aims to organize several development teams towards a common goal by extending scrum across teams which of the techniques below were not added to scrum to create less okay let's what was not added to scrum all right sprint planning more formally divided into two parts what and how okay so that's not a part of scrum but it is that could have been added what and how in sprint planning usually it's just a product backlog isn't it so that's a maybe maybe let's see

what else we've got one single product release with no stakeholder feedback allowed well this one just stands out like a sore thumb doesn't it because what's the point of agile it is to get stakeholder feedback and why do we get stakeholder feedback because by by getting that we get their buy-in and we make sure that we're delivering the product that they actually wanted and you know what sometimes uh us customers or our business or the business or whoever we're delivering value to will give us requirements and then when they see something you know in use

they're like oh i didn't actually want it that way after all because now they can see it it changes the entire game anyway all of that to say this one is probably the one that we're looking at here overall cross-team refinement yes organic cross-team coordination a hundred percent um self-forming teams we want in agile so around a product that people care about or that they're involved in really important overall retrospective focused on cross-team improvements absolutely for that one as well so the correct incorrect answer for this one let's go with answer b and there it

is large scale scrum adds techniques to scrum to create a method that scales across teams it's the scaling method and the organization added techniques include sprint planning with what and how now that's really interesting overall cross-team refinement cross-team coordination across team retrospective and don't forget that shippable increment every iteration if it's possible it's quite hard to do and quite hard to pull off but that's what we're aiming for a project with a single release is a waterfall project as we know or a predictive style of project management great stuff guys let's get into the next

one okay you're working on a project with clear procedures based on past projects the product is clear and the risks are fairly well known as the organization has done this before which is true from the below wow this sounds good and if it's low risk and low change what can we use well we don't have to use agile in this case because it's not a high change environment agile is used um to to respond to change and if we if we don't have to do that we can use a predictive or a waterfall method so

that is a really key piece of information so it's definable work so you can choose a predictive project lifecycle well there we go that's exactly what we're talking about i'm pretty sure that might be the one that we're looking at it's definable work so you can choose agile well if it's changeable work that's when we use agile isn't it so or high uncertainty there you go so high uncertainty you can use incremental high uncertainty you can use iterative yes potentially true we both get with incremental we put all that feedback back into the product and

we have one release and with an iterative project lifecycle we release in features just exactly as that a large scale scrum was saying the potentially shippable product once every iteration if we can help it all of that to say the answer i think we're going for is answer a here and when the situation is fairly definable and well known and the risks are also fairly well known you can choose a predictive project lifecycle that plans most of the project up front and in one single release because there's lower risk now in the real world when

we actually get to doing this usually the risks pop up don't they so i think uh that's where we get hybrid approaches a little bit of waterfall and a little bit of agile or a little bit of incremental or iterative project lifecycle approaches combined and that's just that's life you know that's where change happens that's why we use them alright that was great let's get into the next one you are an agile project manager leading a project team who is used to a waterfall way of work very common the project sponsor wants to plan the

entire project up front so they can see when the project will be delivered you tell them that agile uses adaptive planning why might this be a better alternative okay well this is good this is one so good scenario based question here so adaptive planning allows the project sponsor to adapt to the project over plan over time so the project sponsored to adapt to the project plan no no so definitely not i don't even know what to say it just doesn't make sense uh we'll go back to that one so let's put a cross there for

now but the project sponsor shouldn't have to adapt basically so the idea behind waterfall and and agile is that the project sponsor has a need for business value and we're trying to deliver that value by any means necessary basically so the best means necessary given the circumstances so yeah that's why so adaptive planning allows the team to deliver usable features while continually re-prioritizing the next pieces based on business value well that's exactly what we're talking about isn't it okay well we have a habit of doing this lately we actually answer the question uh just before

we get there so that's what our adaptive planning helps us do and we're delivering value but then we're also re-prioritizing the the next most valuable piece of of of things that we're going to deliver for the business or for the customer and that's why it's so powerful so adaptive planning ensures that users can adapt to the product and again the users are not adapting to the product we're delivered trying to deliver the value for the users adaptive planning is stable after the prototype is complete also not true because things happen life happens even if you

create a prototype someone uses it and says that's great once they get their hands on it things could change again and that's why we need to be open to that feedback and open to change in an agile methodology all right let's go with answer b and there it is adaptive planning allows the project sponsor to receive incremental value delivered as features and as those features uh they can be reprioritized by the product owners throughout the life of the project so that we're continuously delivering the value that they actually want and there's a little joke in

there that uh that many waterfall projects start out as predictive planned and end up as adaptive planned when the schedule and cost projections go uh are not met and they need to adjust and yes that definitely happens all the time all right great stuff guys these are really good questions today so i hope you're enjoying them as much as i am you're a scrum master and you're about to begin a new iteration in your agile project new features have been added to the backlog and the team are unsure which of those features to work on

next how will you guide the product owner and the team when analyzing the next priority and the product owner is our is our main person to represent the customer or the business or whoever we're delivering value to and they're the one who prioritizes that backlog of work or features or you know stories to deliver those features so we need they need to say this is number one you know this is number two this is number three and what is going to give the business or the customer the most value so with that in mind analyze

the value of each feature with the product owner versus the effort and the risk oh and that's so powerful because if something has a high priority you know it has a high value but let's say it's going to take five years to create okay all of a sudden we need to say hmm maybe there's a better thing that we can get in in two weeks instead and it's just slightly less value so these are the things that we need to weigh up the value versus the effort or the value versus the risk so i mean

that one sounds great this one i really really like because of that and that's what the product owner will have to do looking at the value versus risk all the time and weighing that up all the time focus on the shortest tasks first so you can deliver quickly that's not too bad but you know not as good as this one choose to deliver the entire project at the end that's a waterfall one and by asking customers what they want delivered first potentially but the product owner is our guide there so they liaise with the customer

and the business whoever we're delivering value to to and then they're responsible for that priority so let's go with answer a here and there it is while value is typically determined by features that customers want the priority is ultimately decided by the product owner who represents the customer or the business and constantly grooms and prioritizes the backlog of features just as important is developing high-risk items and considering the development effort versus the benefit i mean it doesn't get much better than that that's exactly what we said well done guys all right let's go on to

the next question you're doing great you're coaching some of the team members who are new to agile and someone asks what you mean when you say a time box what will you tell them and you know this is the sort of thing that comes up on the agile exam so agile certified practitioner as well so you're very some of this seems basic but you will it will come up and you will be tested on it it is a period of time in which certain work is completed such as an iteration uh yeah i really like

that one it is a period of time where we uh complete certain work let's see what the other ones are it's time spent on a retrospective not necessarily a time box could be about anything it is time taken to complete the project with the box representing the finished product oh isn't that clever uh no not that one so i mean i like that answer but it's not that because a time box again could be anything could be about a spike where we're trying to figure out or solve a problem uh or it could be an

iteration or it could be your any other piece of work a time boxed so that we're not spending too long on it and why do we time box things really quickly because of parkinson's law have you ever heard of parkinson's law it's where the task or the project or the or the work expands to fill the time that we've allotted to it so if we give something three months if we say hey billy can you finish this off in three months and even though it's like a really small thing to do they're probably going to

take three months and wait all the way up to the end of the three months to finish it off have you ever waited until the last minute to study for an exam that is parkinson's law but you're not doing that because you're here with me studying for this exam so well done you're doing great all right last one uh it's the effort assigned to a story card okay no it's not the effort that is our basically the points story cut points which turns into our team velocity and the team velocity is how we figure out

how much we can complete in an iteration all of that to say let's go with answer a there it is while effort on or time on a story card may be time boxed the best example of that uh is an iteration usually around two weeks an iteration is a time box that delivers a feature or part of a feature that a customer can see feel or touch yeah absolutely that was really good wow these questions are great today all right only a couple to go so you're doing really well while on an agile project team

you prioritize the backlog of features with the product owner that's really good practice to do and agree what you will work on first the project sponsor wants to know how long it will take to deliver some of this value oh this is a really good question how will you estimate how long each of these features will take to complete and this is exactly the sort of thing that you will see on the exam it's scenario based and it's specifically about a problem uh in the real world where people are asking how long it's going to

take to deliver value and you know we have to come up with these answers so this is really really good all right let's see what we've got here so break down the feature into tasks or user stories then estimate how long those tasks will take to complete with the development team yeah i mean again that's that was really good the reason being is because agile looks at uh estimating from the bottom up so there are typically on your pmp exam there are a couple of different estimating techniques there's three point estimating where we give a

pessimistic optimistic and most likely and then we get the average of those there's analogous where we we use an analogy so something similar so is there a project similar or is there a story card similar and we use that to estimate um or there's parametric where we use a parameter and a parameter is uh you know like three meters you know three dollars per meter or a hundred dollars an hour you know some a parameter per you know unit of measure basically and that's how we use to estimate but the last one of course is

called bottom up estimating where we take all the smallest increments for example story cards and we estimate on those individually and they feed up into for example a feature that we're delivering and by doing all of those individually now we have a really good estimate for that particular feature it's bottom up estimating anyway that's a long winded way of saying yeah but you will need to know that sort of thing for the exam and that's why answer a is so good for this one so uh the other ones take the total number of people of

in the team multiplied by hours worked divided by the number of features even though that sounds fancy and complicated that's not the right answer and that's a good uh reason for your good analogy for your life as well the most complicated answer is all not necessarily the best answer as well ask the project sponsor how many iterations the project's funded for and then plan to that uh no that might happen in the real world where we might just keep going until the money runs out or the project is reprioritized but in for this circumstances of

this in an agile team we want bottom-up estimating find a similar feature delivered by another part of the organization and use that as the estimate that's our analogous estimating so we're using an analogy or something similar while that can work and you may use that to estimate on your cards in this case it's not the best answer because we're wanting to get an idea of the feature and basically this will give us the best idea by using points and feeding those back up into the feature so all of that to say let's go with answer

a and there it is agile favors a bottom-up approach to estimating whether work is broken down to give its lowest level typically a user story and estimated by the development team and the testers will need to be involved here and business analysts potentially even this and the scrum master will facilitate but all those people will have an input into how much work they think is in the card so the whole development team the whole team will need to do this which this will give you your estimate of the effort and time required to complete the

feature wow that was really good i hope you enjoyed that one that was a really really good question all right only two to go i think two or three to go guys really really great work you're working with an agile team on your first iteration the feature has been chosen by the product owner and the team breaks it down into user stories to work on what is a user story this is really good so a feature of functionality small enough to come to be completed in one to three days definitely that one that's what we

and sometimes we get user stories that are big so it might be 20 days and we want to try and break so it's a big big you know piece of work can we break that into smaller cards and then assign them smaller values so that we can complete it in one to three days that's the power of you know small increments of work and then those will feed up into the feature and again that combats so that gets rid of parkinson's law because we're not taking three months and we're not waiting until the last minute

and we're not studying you know just the night before our exam right so you know that's uh that's why we use small units and small measures where we can so i like that one too all right a description of the feature from the viewpoint of the customer that is also pretty good that's actually a pretty good one a story about the end user so the team understands the com feature completely that's also sort of pretty good because a lot of the acceptance criteria will be done from the customer's point of view for example as a

customer i want you know something so i can uh you know do something else you know so i can get uh my shopping cart or so i can get something delivered for example and that's our business driven development or um you know a bdd but what is a user story is it a prioritized backlog it's definitely not the prioritized backlog itself so user stories will make up the prioritized backlog out of all of these i really like the piece of functionality small enough to be completed in one to three days even though all the others

are correct the best one for an actual story card itself the other ones really describe acceptance criteria probably so let's go to answer a all right that's great so user story is the smallest unit of work in an agile team a task that can be completed in one to three days if the task will take longer it's common to try and break it into two or more pieces to accommodate that user story rule exactly as we were saying wow we're getting pretty good at this aren't we i think you guys are going to be well

prepared for your exam and now we've got two to go here's the last second to last one you've been begun working on a new project in the organization in a new organization and the project team mentions you are working in an iterative project environment how do you know you're working within an iterative project life cycle okay this is a project life cycle one you will see this sort of thing on your pmp exam the team iterates around one idea to make sure that it's right no no even though we're using the word iterating it's not

that one you're improving the product or result through successive prototypes or proofs of concept yes absolutely and what is iterative so iterative we have one release at the end still so don't be fooled it's just like a waterfall approach and yet what we're doing is we're having successive prototypes and we're getting that feedback and then we're getting that feedback and we're getting that feedback and then ultimately we have a happy customer at the end because we got all that feedback and then released in one go so that's your iterative approach and as we know agile

combines iterative and incremental approaches so we're iterating and getting feedback but we're also delivering in increments or features along the way as well so that's your agile approach uh all right i think b is probably our best one here the project sponsor says the project life cycle is iterative so if the project sponsor says so that doesn't actually make it so yeah we might be doing things differently and organizations will do things differently they will tailor the approach to suit them you are using agile sprints or iterations to manage your work even if we're doing

that that doesn't make it an iterative life cycle so as we've seen we need to be getting that feedback that's our iterative life cycle so let's go with answer b there it is so it uses successive prototypes or proofs of concept to gather feedback and then release in one go well done guys we're up to the last one you've made it and that's ten questions i mean that's a huge amount of questions well done let's see what we've got and oh it's my favorite it's my absolute favorite it's the agile manifesto questions so this is

where this is the high level where agile came from in 2001 a group of individuals representing the most widely used lightweight software development methodologies at the time agreed on a common set of values and principles that became known as the agile manifesto which of the following is one of the agile manifestos core values these are my favorite and these will feed into everything that we do from an agile perspective developing as much as possible to see what gets the best result uh i mean that's that's okay but it's not one of the values of agile

it's more about collaboration and feedback and and change so let's see what else we've got finding a product owner over finding a development team again no not really that's sort of more in the detail but both of those are important cross-functional team members over executive buy-in again probably both of those are important as well well let's see what the last one is responding to change oh and that's exactly what we were saying responding to change over following a plan that means that following a plan is still important however we we value responding to change a

little bit more than following a plan why is that important because of all the reasons that we've just been over in this quest in this question set for example the customer gets their hands on the product and then they say oh that's not actually what i wanted or you know it's this is not what i thought it was going to be like and that's just what happens in life we can't see it until we can actually get our hands on it we can't see all of the things that might go wrong so answer d is

definitely our one here the agile manifesto is made up of four core values one of which values responding to change over following a plan and you made it we made it you've done amazing work and also you're doing great in preparing for your pmp or your acp agile certified practice practitioner exam this is such great stuff and i know i truly believe that you can pass the exam for all the work that you are putting in you are working on a project where the organization wants to move towards an agile way of work which two

project life cycles combine to create an agile environment oh this is good okay and pretty simple so we can get straight into the harder questions later on iterative and predictive uh no so and we'll have a look at these in a second incremental and predictive no so the two ones that combine don't involve predictive predictive is our waterfall approach okay pretty simple stuff but we'll show you why in a second iterative and incremental yes definitely that one and predictive and agile no not that one either so what we're looking at for an agile way of

work is two things uh iterative where we're iterating and getting feedback feedback feedback feedback and then iterative will actually release in one go but if we're combining that with incremental where we're delivering an increment delivering an increment delivering an increment delivering an increment and finally finishing off the project you know that's the combination of those two things is what gives us our agile way of work so let's go with answer c answer c an agile project environment is created by combining incremental uh where smaller features are released more regularly and iterative where the product improves

through iterations and is released after the feedback that was a really great way to start and a good definition of agile let's get into the next question you have come on board a new project team and you've been advised that the project works with a predictive style of project life cycle okay this is the other side of the scale this is good a really good foundation how will you know you're working in a predictive or waterfall waterfall style approach all right the bulk of the planning is done up front and then executed in a single

sequential process yes that's definitely it we plan everything up front and then we go step by step by step by step all the way to one single release right at the end that's our predictive we're predicting how the project will go and be released that's probably the right one let's see what else we've got the bulk of planning is done up front then prototypes are created no that's iterative because we're getting feedback from those prototypes and then releasing one go remember a product roadmap is created and smaller features are designed and released as part of

the whole that's probably more incremental because we're delivering in smaller increments or features and lastly the project uses feature sprints kanban boards and retrospectives to manage their work that's not really about the project life cycle that's more just about the tools that we're using so for a predictive or waterfall approach let's go with answer a and it's important to know this because we need to know what's agile and also what's not agile and you know and the different methods that we're going to use for each of those approaches and the different times that we're going

to use those approaches as well when there's low risk and low change then we can use a predictive method very easily and that's good to know so anyway all of that to say all the planning is done up front executing in a sequential process ideal for definable work and products where the risk is well known exactly as we're saying great stuff all right on to the let's go into a little bit of harder questions i think here maybe more on agile let's see what we've got you're working as a project manager in an agile team

which of the below are not examples of execution practices you will see in agile so these are the things that we'll do on a daily basis to execute our project in an agile environment we've got test at all levels where the team applies end-to-end testing and unit testing so we're testing at the small at the story level and then we're testing when there's a bunch of stories together so we're doing overall testing but we're also doing you know single story testing we're testing at all levels of the project agile teams prefer automated tests so once

all of those cards have been created and let's say we put them into a test environment along with all of that we merge them you know with all of the other code and then we run an automated test or a bunch of tests if we can to make it fast but also to quickly see if anything has broken when we've merged it with the rest of our code and that's just a really great way to do it it's fast and we get feedback quickly so i really like that one test driven development where we write

uh the tests first and then we write the code and then we once the code is written we test it again to see if the test has passed that's test driven development a really good practice in agile spikes which are time-boxed research or experiments for useful are useful for estimating uh or figuring out acceptance criteria or learning something critical yes about technical or functional element that we're looking into basically a bit of research a bit of uh discovery work that's our spike and it's time boxed so we don't spend too much time on it and

that's a really good practice as well the project management plan where the project is planned in detail up front to avoid misunderstanding by project stakeholders that's more of an iterative more of an more of a predictive sorry or waterfall approach is answer d and i think answer d is the incorrect one the one that we're not going to see in an agile team and there it is a project management plan is a key artifact in a predictive or waterfall project management approach test at all levels test driven development and spikes are all agile practices that

you will see well done guys all right only a couple to go let's see what else we've got the product owner has worked with the development team to list all the work to be done write up the user stories for each feature and place them into the product backlog what will you do next oh and this is great a good scenario based question let's see what we've got okay what will we do next groom the backlog to ensure only important items are being worked on i mean that's that's kind of okay create the schedule management

plan no that's more of a predictive or a waterfall approach there schedule management plan um and your project management plan and your quality management plan and your scope management plan all of those things are predictive what all waterfall approaches sort the items by business priority place them in an iteration complete the items and then remove them from the backlog cool that's a whole mouthful there but yes that's exactly what we'll do uh once so we've written up the user stories we've placed them in the product backlog then we sort them by business priority place them

in an iteration complete those items and remove them from the backlog i think that one's looking really good so far lastly move the items into the requirements traceability matrix so you can report on their progress uh requirements traceability matrix is still really important and you might see this used in an agile team as as well as a you know a predictive method or a waterfall project as well why because we actually still want to know that our requirements are being met and this is where our business analysts will come into it and so still very

important work to trace those requirements to the story cards or the work that is being completed uh all of that to say that's not what we're going to do next even though you may use that tool along on your project we're still going to sort by business priority place them in an iteration complete those items and then remove them from the backlog so let's go with answer c there it is managing the project requirements via the product backlog is a fundamental agile practice the product backlog is the source of truth and is continuously reprioritized as

the work gets done to ensure maximum value is delivered first and that's a really great way to work and also we're up to the last question for today so well done guys you've done great let's see what we've got the business partner or product owner continuously refines or grooms the product backlog this includes adding new stories reprioritizing stories and removing stories when needed what role does the development team take during this process oh this is good developing the cards as soon as they're added to ensure maximum value not necessarily we still want to put them

into our sprint backlog as long as they're prioritized uh that the product owner says that that's what we want to work on so maybe not that one removing cards from the backlog that don't make sense to complete again that's not our role that's not the development team's role because the product owner needs to prioritize these things estimating the work needed for each card so the product owner can prioritize based on value and effort yes really really important now the product owner needs that information how long is it going to take if it's going to take

20 weeks then maybe we need to figure out if we can work on something else instead that's going to deliver us the same amount of value really really important okay i think that one's probably our one coming in to daily standups to report on what has been done yesterday and what will be done today yes everyone will come to the stand up or anyone who wants to but that's not what we're going to do during the process we prefer to get the work needed for each card so estimating the work so the product owner can

prioritize let's go with answer c and there it is during backlog grooming the development team is responsible for sizing or estimating the work this allows the product owner business representative or customer to prioritize effectively based on value and time to delivery and that's our five questions for today you've done a really great job and i know that you are preparing in a great way for your pmp or your agile certified practitioner exams where agile is becoming more and more prominent in all of these things and in the work that we do on a day-to-day basis

you're working with your agile project team to estimate each task and how long they might take the team is finding it difficult to give an exact figure and worries that it might impact project delivery what can you show them to estimate more accurately okay this is good so let's have a look we can ask them to estimate by whole iteration to give a little room for variation no in an agile team we still want to be able to estimate by cards and then we roll that up so we've got three points five points two points

five points here that rolls up into our overall iteration so that's the preferred method what else can we do estimate the cards in full days instead of effort per card no not full days because what if a card is just going to take half a day so probably not that one and that's going to be less accurate as well isn't it so let's have a look at what else we've got use comparative estimates or relative sizing such as t-shirt sizing or story points so relative and yeah that's exactly it when our when we're estimating it

doesn't have to be exact but it just gives us a broad idea so story points would be usually in the fibonacci sequence so 1 2 3 5 8 13 and usually if something's bigger than 8 we don't want to we want to break it down so 8 or 13 can we break that down into smaller stories but that the way that we measure that is just amongst the team so the team will agree uh on you know what those particular numbers mean just like t-shirt sizing small medium large extra large or extra small for example

uh you know the team can agree on what those actually mean amongst the team and it might be different in a different team might be similar but you know probably different a little bit different so you know that's part of how we do estimating correctly so let's go with answer c here but the last one prioritizing the backlog based on customer value that's just not related at all so let's go with nc there it is a common agile practice is to rely on relative sizing such as story points or t-shirt sizing team velocity is then

measured using those same methods as the team completes a certain amount of points per iteration this is easier than trying to predict an exact time period so we don't really want to try and predict we just want to figure out what we have to do and then figure out how long that's going to take pretty easy stuff when you get into it alright that was a great question to start off let's see what else we've got you're an agile project manager and talking through the iteration with the product owner they have created the list of

items in the product backlog which is great that's the best practice that's what we want from our product owner in the team but there is confusion in the team about who should perform the process of story card sizing what will we tell them oh all right let's see what we've got the product owner works through the backlog to size the story cards no it's a team effort we want the developers involved the test is involved business analysts scrum master even a product owner all of the people together but most importantly the people who are doing

the work so developers and testers in most circumstances will give the best accurate best and most accurate advice for sizing these cards the agile team work together to size the story cards relying mostly on information from the developers and testers isn't that funny that's exactly what we just said so that's great when that happens okay so it's probably going to be this one let's see what else we've got the agile team leader or scrum master works to size the story cards for the team no and so when we're so even though we're saying servant leadership

serving doesn't mean doing everything for the team it means growing the team and it means removing blockers so the team can do their best work themselves so that's the when we say we're servant leaders we're not actually doing everything for them we're helping people do the best that they can possibly do and be be the best that they can possibly be so that's uh that's a good idea there the customer sizes the story cards to ensure maximum value how can they know how can the customer know what the effort is going to be required so

we need the developers and testers to do it so let's go with answer b there it is the story point sizing process is performed by the agile team primarily estimated by developers and testers who will be doing the work so they will know best great that was a really good one to start off with as well this is good stuff all right let's see what else we've got next okay you've been estimating story cards with your agile project team but the effort captured has not been matching the time it ends up taking to complete oh

oh this is this is such a good one and this is the sort of thing that you will see on your exam it's a scenario based and it's a problem uh so this is a really good question to go through what is the most likely reason for this occurring okay the team have not included sick days in the estimate no because sick days are how much the team can complete but the sizing is still done per on a per card basis so it's not that one the team have not included testing or refactoring in the

estimate that's a pretty good one because yes we want development work we want testing work and if something if we're doing you know hacky fixes or like quick fixes that are making messy code or you know having your systems talk in dodgy ways to each other not in clean ways so that's when we're going to need refactoring of the code to clean up the code to simplify the code base and simplify the systems later on but hopefully we're doing that when we're developing it in the first place if we can so that might be happening

so i think that's a really good one that could be giving us more time could be taking more time for the guys in the team the team have not included time to merge the code for continuous integration continuous integration should be automated where possible so you know yes it may take a little bit of time but that's more for the release that's not for the development of the card and then ideally it should be automated as we merge two to the one code base and then automated tests run on top of that as well that's

our continuous integration and configuration management all right so let's see what the last one is the team have not included the time it takes for the daily stand up that's not really part of estimating on a card so i think probably the best answer here is including testing which is a hundred percent uh correct really is a must but refactoring as well is very important so let's go with answer b and there it is estimates for story cards should include all known activities required to complete that card including testing and including refactoring and the complexity

and risk involved as well so that's really important great work guys alright two to go you've done really good job you're an agile team leader and talking through the process for your first retrospective the team is curious as to what they should do what is the way a team retrospective would normally work all right discuss what was successful what could be improved and incorporate those into future iterations uh yep that's definitely a retrospective so we ask what went well what did not go well or what's still what's a challenge what was the challenge um what

still puzzles us um and i think they're really the big ones the i think there might be a fourth question in there somewhere but those are the ones that are you know the best to ask during a retrospective what else have we got discuss what the team liked about working with each other uh i mean in a way yes but not really part of a retrospective discuss what went wrong and make sure the team knows who is to blame blame is not a part of agile at all so when we're asking about what went wrong

we're asking what the process went wrong so how can we fix the process how can we improve the process it's not about the people the people we want to be you know we want good people to be on our project open to change and working as a team but ultimately it's not blame if something goes wrong we want to try and improve the process and make things easier and remove blockers for our team discuss the validity of features being developed that's more for our product owner during before iteration planning they should prioritize those features for

us so i think the correct answer here is answer a and there it is a team retrospective enables the team to answer questions that improve their team process and way of work such as what went well what could be improved and what still puzzles me exactly as we said well done guys and we're up to the last question you've done great here it is let's see what we've got the 12th principle of agile is at regular intervals the team reflects on how to become more effective then tunes and adjusts its behavior accordingly in practice this

is a retrospective exactly as we just saw but what is the practical reason for including retrospectives in an agile team oh this is good all right it reduces the communication time between the project sponsor and the developers ah maybe but maybe that's more of a stand-up where we're getting everyone in the same place so maybe not that one it ensures features are released on schedule and on budget not necessarily it's more about continuous improvement here it helps the team learn about and improve their process over time yes we're improving the process that's what we want

and it keeps the team focused on the main feature to deliver the most business value not necessarily prioritization is done by our product owner and put into the sprint backlog at the beginning of the sprint during iteration or sprint planning so all that to say retrospectives for our process probably improving our process over time let's go with answer c agile retrospectives help the team learn about their process and improve it over time through regular and structured feedback given and used together as a team and now we're growing as a team and improving as a team

and before you know it we're delivering amazing things in record time because of all the we're improving in its small increments over time and that's the power of agile and working in an agile team and well done guys you've made it through the five questions very quickly very easily i truly believe that you can pass your pmp or your agile certified practitioner exam and i know you can do it because you're doing such wonderful practice and wonderful study every single day i truly believe in you retrospectives are typically held at the end of an iteration

but an agile team can hold retrospectives at any other time what is not a time that an agile team might hold a retrospective well we've got when the team completes or ships something new so this is what what is not a time so yes we we do want to have a retrospective when the team completes something new or or ship something new when more than a few weeks have passed since the previous retrospective yes it's good practice to hold them at least every couple of weeks at least every two weeks around the end of your

iteration usually when the team appears to be stuck and completed work is not flowing that's also a good time to hold a retrospective so we do want that or lastly when the feature backlog has not been created and work is yet to begin typically a retrospective is about work that we've done already or how things have been going so if we haven't started yet probably not the best time to hold a retrospective let's go with answer d answer d a team retrospective is there to gather feedback and improve on the team process once that process

is in place it iterates towards improvement and it's not held before the work or the process has begun as there's nothing to gather feedback on yet so that's a really good one what a good question to start with all right let's get into the next question you are in a new project team and working through which project life cycle or way of work to use in order to deliver the products to your customer and how far to modify that project lifecycle okay this is tailoring the project life cycle what are some of the project factors

that will influence your tailoring decisions to use agile or other methods okay let's have a look which project life cycle the customer wants to use typically the customer won't have an input into the project life cycle that we're using it's based on what type of work we're doing so is it high risk is it high change then we're probably going to go with agile if it's low risk and low change then you know would better with a predictive or a waterfall approach the customer will give us information on what they want delivered but not the

project life cycle what the latest life cycle is the one that must be the best and most interesting to upper management no not that one either although that will happen in an organization people will follow the latest fads uh typically it's best if we understand when to use project life cycles so whether the flow of work is often interrupted by various delays or impediments and is easily definable or highly uncertain and that's exactly what we were talking about here so is it high uncertainty work does it need a lot of change is there a lot

of risk involved so that's probably going to be our best answer there and lastly project approaches should never be tailored no that's incorrect project approaches should be tailored we want to tailor them to our needs why because projects are different everywhere you go the organization is different the product is different the people are different the market is different the industry is different that's why projects are so interesting and also so difficult so let's go with answer c answer c project life cycles and how much you tailor them depends on many factors having definable work or

high uncertainty work are two of those common factors so you'll see that on the exam as well and as you as you move towards predictive or incremental workflows as is the team's existing experience so what what what experience does the team have do we need to make lots of changes or are you know is the the risk low all right that was a really good one as well let's get into the next question you're working you're in the forming stages of a new project team uh and as we know this is tuckman's ladder you'll probably

see this on the exam as well where you've got forming storming norming coming together and then performing and then adjourning you know right at the end there as well but that's tuckman's tuckman's ladder or the tuckman model what are some of the factors that will influence how you tailor the product life cycle because we're deciding on the way of work all right let's have a look the demand pattern for value or delivery is it steady or sporadic yes that's a good one the rate of process improvement required by the team do we need retrospectives or

can we just continue and deliver in one big bang that's a good one as well is more than one team needed to build the product uh i mean yes i think that sort of does feed into it maybe um so these two are really good this one's a maybe um i mean probably the best answer here might be all of the above let's see how we go all right there it is project life cycles are ways of working can be influenced by many factors in fact almost everything will impact this decision and you will see

this a lot so the way the organization works whether the work is certain or uncertain these are two good things whether the features are subject to change really big thing and what has worked before and what the team is comfortable with as well all of those things will play a part all right there we go i think i've learned something today as well let's get into the next question you're working through the backlog with the product owner and estimating the story cards with the development team the team have never worked through worked on a product

like this before and they're unsure if the estimates are accurate enough what will you recommend that they use to get accurate estimates okay let's have a look affinity estimating using actual effort from similar feature on a different project uh that's a pretty good way so i mean i've used that in real life as well so if there's something that people know that they've estimated on in the past and they've seen how much effort that has taken we can use that as a guide for our new team to estimate on this new feature as well as

long as it's quite similar so that's quite a good one t-shirt sizing using broad small medium or large sizes to accommodate variation i mean this one's okay as well it usually it's it's a bit broad so it might not be exact we might not get the right information here usually we use t-shirt sizes at the beginning or for larger pieces of work because there's so much variation involved okay let's see what else we've got three-point estimating where we've got the pessimistic most likely and optimistic and then we average all of those out um that's not

really found in agile agile is either affinity estimating but estimating on the actual card and the cards themselves and then that's bottom-up estimating where all of those items are feeding into the overall estimate basically um okay let's see what else we've got the product owner should estimate the story cards no the product owner does not estimate the story cards the whole team or the people who are doing the work the development team the testers so anyone actually doing the work should be estimating on the work so i think the best answer here is answer a

there we are answer a while most estimation methods will do the best one in this case is affinity estimating using a similar example from a previous project agile estimating is most often done by breaking the features down into small tasks as we saw over here and then estimating on those tasks which is bottom up estimating where that doesn't work affinity estimating is the next best choice all right good job great great stuff guys this is really good all right i think we're about halfway there let's keep going you're delivering features through your agile project and

the project sponsor and product owner are happy with the progress that is a wonderful thing and you know it's happy days when that happens your project sponsor raises a concern about future items and what that development will look like what will you show them all right the project management plan no that's more of a waterfall so you'll you'll still see this in the pmbok guide and in your project management or pmp exam the but the project management plan is more of your uh waterfall or your predictive approach where you're planning it all up front you've

got your schedule management plan your scope management plan um requirements traceability matrix and all of those things feed into all of those quality management plan everything's planned up front and then it's delivered in one big bang but that's not an agile way of work so let's not go with that one for now the product backlog that's all of the list of the items that we're looking to develop so that could be good for future items and what development looks like the product roadmap that shows planned future features and their approximate dates similarly to a gantt

chart that's probably the best answer there and that's usually created by the product owner they'll have a vision they'll have this feature is coming in this feature is coming in this feature is coming in uh approximate dates uh just a high level idea but now we know when this when this feature is going to come and impact our customers or our business that's probably the best answer so far the team velocity chart that shows how much the team completes iteration look that's another good one and if we have the product backlog and the team velocity

chart together then those two things can give us an idea of of what we're delivering and how long it might take but um but yeah probably it's not really about the future items and what that development looks like so the broad features probably the best answer here is the product roadmap let's go with answer scene and there it is a product roadmap is a visual display of the product releases similar to a gantt chart or a project schedule but it's based around agile feature releases high level view adjusted as necessary usually done by our product

owner all right that was a great question let's see what else we've got you're doing great keep going the agile team is estimating story cards using planning poker for one of the larger features some of the team have estimated three points while the others have estimated eight points how will you guide them to come to an agreement and this is great you'll see this come up a lot in your agile team we can ask them to average out the points and assign the value to the guard we don't want to average because we want people

to have a voice and say why is it low or why is it high and then we discuss so change the method of estimating to accommodate the team decision we don't want to change the method no not necessarily change the feature to make it easier to estimate on no we don't want to do that either because whatever the customer wants we want to try and deliver that ask the high and the low estimates to discuss their reasons and the team to estimate again until a consensus is reached or more information is needed maybe we need

to go away and get more information but if we've got our five and our eights and they're saying okay well it's eight because of this reason and it's five because of this reason if we if we can't discuss and come to an agreement then maybe we need to go away and get more information and then we can come back to it so i think answer d is the absolute best answer here let's have a look there it is in planning poker if the estimates are different high and low estimators share their reasons once shared the

team estimates again and that's repeated until a consensus until everyone agrees basically or we decide to gather more information great stuff guys you are doing great last couple of questions let's see what we've got the agile team is working through a particularly complex feature that is difficult for the team to find a solution for as the agile lead you recommend a spike what is a spike well this is a good one uh okay and let's have a look at these initially uh already i can see the spike you know because this is nice and easy

it's just a definition a spike is a time box task to explore or investigate an issue it's not necessarily development itself it's more research so gathering information so let's see look at the others a shifting of the feature into another iteration no that's just backlog management so that's fine a short meeting to at the beginning of the day to discuss tasks in progress that is your stand up so that's not it either and lastly a demonstration of the feature to the product owner owner that's our sprint review or our demonstrations or reviews at the end

of an iteration so it's not that one as well let's go with answer b there it is a spike is a time box task to explore or investigate an issue and that's really great it's separate from development work and it's only used if something needs to be figured out or investigated great job guys all right let's see what we've got next you've been completing small usable increments of value as part of your agile team when reporting back to the project sponsor of this project the last iteration was referred to as a fast failure what does

that actually mean all right let's have a look at this and see what we've got the iteration did not complete all the story cards in the allotted time not sure about that the project team found a bug uh before code delivery not not necessarily as well even though those are sorts of failures but if something has failed then it's uh then it hasn't delivered what we wanted it to deliver it's a fast failure we're learning from our mistake you might call it a minimum viable product and we're learning and from that perspective we've gotten value

but maybe we need to adjust our approach going forward so the proof of concept for that iteration did not have the intended outcome and that's exactly what we're talking about there the the proof of concept uh or the the feature or that sort of thing that's probably what we're going for as a fast failure the product backlog was not well groomed to start the next iteration that's just a process um thing in agile so that is that's totally fine not really related to this question let's go with answer c all right great the agile agile

depend operates on the concept of delivering increments of value features that we're delivering consistently fast failure means that particular increment was not successful it didn't deliver what we wanted it to and now we need to adjust very simple and part of the beauty and the power of agile alright great job guys all right last two questions you've done absolutely great work keep going we've got last two sca and oh now we've got scaling frameworks so this is good stuff scaled agile framework or safe you'll see this come up quite a lot because it's a bit

of a combination really between uh waterfall and agile so you know and it's quite well defined so you'll see organizations latch onto this pretty well you know whether it's exactly agile or not is another story but it's a scaling framework so roles and activities in the portfolio program and project levels focuses on organizing the enterprise around value streams that provide value to the customer what is not one of the principles of safe take an economic view and apply systems thinking that's definitely it systems thinking is where a small piece of a small change will it's

like cogs in a wheel that will affect that and that will affect that and that piece will affect that piece and so ultimately it ends up affecting the whole system as a whole visualize and limit the work in progress reduce batch sizes that's a good one as well that's a common agile principle limit the work in progress that's our kanban work on the wall plan carefully for large single feature release maybe not let's see what else we've got build incrementally with fast integrated learning cycles probably that one and again with any of these questions around

the agile frameworks your additional frameworks just go back to our normal agile normal agile principles and so for a single large release that's more of a waterfall item so even though you know safe it can be a combination of waterfall and agile basically let's go back to the agile principles themselves and for the purposes of this let's not choose the one that is a single release because that's more of a waterfall and less of agile so let's go with add with answer c is the incorrect answer okay that's great so agile safe uses the agile

principles but scales them across teams and across the organization these include systems thinking visualizing work in progress building incrementally planning long term for a single release is a predictive way of work and you've done so well we're up to the last question scaled agile framework again focuses on detailing those practices roles and activities in the portfolio program and project levels it organizes the enterprise around value streams what is not one of the safe principles all right this is good we're getting a good view of safe here so make sure that stakeholders know when you did

more work than your teammates well i think right away we can say that that is our incorrect answer here let's see what the other ones are apply the cadence for synchronizing with cross-domain planning okay i mean that's a long way of saying scrum of scrums so really we want to be catching up and representing our team across the other teams or in a predictive program you might call it a program so you know in a normal predictive way of work you'll call it you've got your projects they feed up into a program multiple programs feed

up into a portfolio and this is just the same thing except we're managing it using an agile way of work with scrums and and short meetings unlock the intrinsic motivation of knowledge workers a hundred percent and decentralize decision making um so yes we don't want that decision making to be centralized everyone can be part of that decision so the incorrect answer answer a and there it is agile focuses on individuals and interactions over processes and tools so people are one of the most important aspects in a team and we focus on those interactions and there

we go you have done it and we've got a few extra things on scaling frameworks and that sort of thing so that's really really great i've had an absolute blast doing these questions with you and i hope you've had a good time too i also know you are well prepared for your exam keep going because i absolutely believe that you can pass your exam your agile project team has been delivering value to an organization in increments for some time executives within the organization would like to scale the approach across more teams to gain benefit from

its way of work all right this is a scaling agile question this is going to be really good which of the below is not a scaling framework from agile that you might use okay let's have a look at scrum scrums it definitely is safe or scaled agile framework definitely is kanban iteration retrospective um that's not a real scaling methodology well although it sounds pretty cool but that's definitely not it large scale scrum or less is also a scaling methodology so the correct incorrect one for this first question is answer c answer c scrum of scrums

scale agile framework and large scale scrum are all scaling agile frameworks all right that was a nice and easy one to kick us off let's let's see what we've got next the organization you're working on has decided to move towards an agile way of work and project life cycle approach which of the below is how you would describe an agile project life cycle oh this is great and you'll see this on the pmp exam about life cycles or project life cycles as well so what is an agile way of work it's both iterative and incremental

to refine work items and deliver frequently well we can pretty much look at that one and say that's actually the one but let's look at the other ones and see what we've got both iterative and predictive so iterative is where we are iterating but we still deliver in one big bang and predictive is just where we deliver in one big bang but plan everything up front so it's not that one both are fast and furious designed to deliver the most bang for your buck i think someone could create a framework about that but uh but

that's not the one for our case we'll save that for the movies the both predictive and incremental predictive anytime it's predictive it's probably not going to be an agile way of work because it's all planned up front and agile we want to adjust we want to take an incremental approach where we're delivering in increments but also iterating uh and improving over time so let's lock in answer a answer a the agile project life cycle is a combination of iterative where we gather feedback and incremental where we deliver smaller usable features to of value to our

customer all right great question all right these are going pretty well there are four main project life cycle approaches to managing a project with variations in between what is one of the characteristics of an iterative life cycle approach and we were just talking about this so this is really good timing it does not allow feedback no that's not it it allows feedback for unfinished work to improve and modify that work that's probably the one that's what we were just talking about where we take that feedback but we still deliver in one inc one piece of

value at the end see it focuses on delivery not feedback no and it plans the project up front and delivers in one go not necessarily it does deliver in one go but we do gather that feedback to adjust over time so let's go with answer b answer b an iterative project life cycle iterates towards success it uses prototypes and unreleased versions of the product to gather feedback and improve it before releasing it in one go all right that was really good too let's see what we've got next you're working through a sprint planning meeting with

your team the team has sized up the cards and prioritized the backlog what will you do next to determine how much work can be done during this iteration oh this is good count up the user stories that the product owner wants completed by the end of the iteration but we still need to figure out how much the team actually can complete so that's what we want to be completed and that's the product owner's decision of course but let's see how much we can complete check the team's velocity and that's so the team's velocity is how

the average of what we've completed over previous sprints so that gives us an idea of how much we can complete going forward so against the number of points for the story cards that we want to complete that's probably going to be the one let's see the others ask the scrum master to allocate work to each team member in the fairest manner possible that's not really related to what we're trying to do here and look at the other teams and what they did in last iteration to give us an idea for our team that's not good

either because we just want to look at our team and figure out how much we can complete every team will be different and every team might even measure their approaches slightly differently as well and that's totally fine as long as it's agreed within the team so for our purposes let's go with answer b answer b velocity is the amount of work measured by points hours cars you know t-shirt sizes or anything that you wish as long as it's agreed with the team most often by points though a team completes on average in a given sprint

by checking those total points and checking them against the possible team velocity then we'll figure out how much we can complete in the upcoming sprint that's great all right good job guys let's see what we've got next you're an agile project manager working on the next feature for your product the product owner has asked you for an estimate on how long the remainder of the features may take to complete you look to the team's velocity chart why is this the team's average velocity across previous iterations is the best predictor of future iterations and yes that's

true so that's going to give us a really good idea of of how long the remainder of the features will take to complete let's see what else we've got the velocity ensures the team will never work harder than they have to not necessarily true because once we finish things we can pull extra cards onto into our sprint if we need to and onto our kanban board so we can track them the scrum master has the final say over team velocity to ensure the work gets done also not true because it's just a measurement of how

much we're actually doing and basically we don't want to overload our team so we use that measurement so that we don't go too much over what what we've done previously so we're not overloading our team we've got a consistent flow of work and it's manageable flow of work lastly the velocity chart shows how quickly new items are picked up by the team that's also not correct it just measures how much how much the of the work is flowing through the team and how quickly usually by a measure of story points on the cards getting completed

so let's go with answer a the average velocity or work completed during each iteration is the best predictor of future velocity because previous iterations typically include all of those tasks and pitfalls that we might come across in the future as well all right that was great next question you are the lead agile lead or scrum master for your agile team and planning the next iteration it's about to begin so what will we do before planning the next iteration let's have a look break down the features into user stories that's a possibility so before we're planning

for the next iteration write the story card acceptance criteria within the team that's also a possibility choose which stories the team will work on in the iteration uh probably maybe and work with the product owner to prioritize the highest value ones to work on okay this is probably the most promising here and because we're the agile leader or with a scrum master so we may not necessarily break those features down into stories that's done by the development team and our business analysts and the product owner will work with them to do that we we won't

write the story card acceptance criteria because that's done by the business analysts in in with help from the developers and testers and the product owner again so ultimately for us we want to figure out we want to work with the product owner to prioritize the highest value ones and put them into the backlog so that we can then make sure that they have points on them and figure out how much we can complete in that iteration but prioritizing it according to what the product owner wants is the most important thing for us at this stage

so let's go with answer d during iteration planning the team should have already broken down features into story cards so that's good now is the time to re-prioritize those cards to be done based on the business value and the team velocity so what can be completed so that's also good to know all right how did you guys go let's get on to the next question only a few to go you're in the middle of a sprint with your agile team and moving the project forward with daily stand-up meetings what is a stand-up meeting oh this

is going to be a nice and easy one so it's just a definition of the stand-up meeting let's see what we've got a project kickoff meeting no it's not that project progress meeting oh sort of will you see how proposed schedule stands up against the actual schedule no that's more for your project management plan or your predictive way of work where you've got actual schedules that you're needing to work towards okay let's see what else we've got a very quick meeting time boxed at 15 minutes or less that's definitely it where the teams say what

they have accomplished and report any blockers yes that's our stand-up meeting and lastly a team training meeting no that's not it either so as you know the stand up usually held once a day and 15 minutes people report what they've done and what they're planning to do but also mostly any blockers is anything blocking us from doing the work can we swarm around that and fix that as quickly as possible so answer c is that one and there it is and that's uh where we do it around the kanban board as well and the team

goes through everything they've accomplished but most importantly any blockers all right that was a really good question let's see what else we've got you are the agile project manager working on a software project and the development team have identified a major risk for the delivery of a certain feature that feature is not scheduled until very late in the project what will you do next oh this is good okay wait until later in the project as the problem may be fixed by other features going in no and in general just so that you know with risk

in an agile project typically we want to turn it into a story card just a risk card usually but we want to fix and complete that risk or work on that risk way up front so we want to to get rid of all of those risks way up front in the in the early in the project because the longer they go on the higher risk they do become and the more expensive they are to fix so that's just a general guideline for us there let's see what else we've got ask the developers to find a

way to proceed without that feature no because we still may need that feature so we we still have to do that plan a spike around the risk to identify a solution then prioritize that feature earlier in development that sounds possible and the spike part is also really good so doing a bit of research around that you know what do we need to fix that risk so that's quite good let's uh i like answer c and answer d remove all other story cards from the current sprint so the team can swarm around the issue and fix

it we can't do that either because we still have to keep delivering value if we if possible so that's why we set it aside have a spike to do the research around it and then prioritize the solution as early as we possibly can so that leads us to answer c answer c agile risks are prioritized early in development to reduce and remove those risks discovery work is typically typically done with a spike card so that's what we know but it does not need to be done by the whole team so we can still keep delivering

value so allocate a certain amount of time to it then prioritize it early so it's taken care of and we know what we're dealing with all right that was a really really good question i really liked that one let's see what else we've got i think there's only two to go guys so you've done a really good job your agile project team is using scrum to manage the work and deliverables for your project which of the below is not one of the scrum events or artifacts okay let's see the product backlog yes that definitely is

and that's where the product owner manages a prioritized list of planned product items which evolves from sprint to sprint because the priority might change just depending on what we know the sprint backlog that's what goes into the actual sprint so we've got our product backlog and some of those items might go into our iteration or our sprint just depending on how much we can complete increments or features which are all uh which are all the product backlog items that can be completed during a sprint and a step towards the main vision potentially yes that's definitely

a maybe but i don't know if it's a scrum in particular so even though it's definitely agile and we'll usually demonstrate one of those increments or features at the end of a sprint review so yes i mean that's a definite possible one as well and the team area which is where the co-located team sits for fast collaboration look that's also a good one so these are all really good so because we could choose any of these from an agile perspective let's go back and look at the question we're asking for scrum events or artifacts so

product backlog is an artifact sprint backlog is a is an artifact increments or features are artifacts um that were you know or items that were that we're delivering so completed during a sprint and the sprint is our event as well team area is basically just a team area even though yes we definitely it's definitely part of agile probably that's probably the one that doesn't fit the most so this is quite a tricky one but let's go with answer d all right scrum works with a product or feature backlog a sprint backlog and delivers in increments

or features agile teams are typically recommended to work in a co-located space but this is not one of the events or artifacts from scrum itself okay that's good to know and also that was quite a bit that was a little bit tricky so we had to go back to the question and just because they all fit an agile methodology so we had to look at the question itself and delve into that a little bit more all right last question guys you've done great your agile team has been working with scrum for some time now and

have become quite familiar with its events and ceremonies you're asked to explain this to other stakeholders within the organization what is not an example of a scrum or event or a scrum event or ceremony okay all right and right away we can see this you know is this is really just an idea of what happens in scrum so we know scrum has sprint planning where we're planning the sprints and we select the highest priority items to go into the sprint we know we have the daily scrum or the stand-up where the team meets to talk

about their project tasks we know we have the sprint review which is where we demonstrate a feature or a working piece of software that was delivered during the sprint and we so the change control board is the only one that is is not the same that's where all proposed changes are reviewed before adding the backlog adding to the backlog that's more of a predictive or waterfall approach so let's go with answer d as the incorrect method here the change control board is a typical part of a predictive or waterfall project life cycle not an agile

or scrum way of work and there we go you've done great so we've finished it you've done 10 questions and you're preparing in a great way for your pmp or your agile certified practitioner exam i completely believe in you and i know you can pass the exam scrum is a single team framework for managing product development so we're talking about scrum here one of the main aspects of agile there are certain events ceremonies and roles and responsibilities within a scrum team which of the below is not a role of responsibility in a scrum team okay

and this is quite good as well because this is just a simple definition so who's involved in a scrum team and we can already see outright so straight away we know that we have a product owner who prioritizes the backlog the development team who actually develop the items and create the create the the features and the story develop the story cards and the scrum master who facilitates all of our ceremonies and that sort of thing as well and but lastly our risk manager even though you know a risk manager is certainly important and it's more

of a predictive more of a role in a predictive method or project life cycle that's probably not within an agile team itself and certainly not within a scrum team itself so for our purposes let's go with answer d answer d risk and quality are the responsibility of the whole team in an agile way of work okay so that's good so typically a single person is not responsible for it the product owner ensures the right features are developed delivered the development team ensures the code is refactored and streamlined and simplified regularly and the scrum master ensures

that the team process has improved over time and the quality tester ensures that features are free of defects so all of those aspects cover a lot of the risk that you'll see on a normal project but everyone works together to work on risk in an agile project so that's really good all right that was a great one to start with all right let's see what we've got next agile servant leadership is one of the key foundations to an agile team where leadership and team participation and openness are encouraged which of the below is not one

of the characteristics of a servant leader okay this is going to be good promoting self-awareness and helping people grow that's wonderful that's what we want in servant leadership we want to be growing our teams listening to others more than speaking yourself yes that's also a good one because we need to listen and figure out what the blockers are and what the troubles are within our team serving those on the team by removing blockers well that's a good carry on from the from the previous answer so yes i love that one as well let's see what

the last one is reporting on low performers to ensure the team is streamlined so that's not part of agile servant leadership or servant leadership in general basically we want to be growing our team so definitely where we where possible as long as a person is open to it we want to be growing them and helping them improve which ultimately helps our whole team improve as well so let's go with answer d answer d agile and servant leadership work by building towards psychological safety openness growth and ensuring work is free from blockers it starts with the

scrum master or agile coach leader role but expands to the whole team and that's a wonderful way to put it all right good way to start let's see what we've got next your team are about to proceed with the development of a new product for the organization you work in depending on the product stakeholders risk appetite need for value and more the life cycle or way of work will change which of the below represents an incremental life cycle approach and if you've watched any of these videos we will know that increments are our features that

we're developing and releasing over time so uh basically let's see which one we've got here it provides unfinished deliverables no that's not true because we want finished deliverables so they have to be complete in themselves usable parts it provides value in one release no also no because we want multiple releases they're multiple features it provides multiple finished deliverables that the customer can use immediately yes that's definitely looking good for that one it provides a way for the team to do less with more by releasing only a small feature no not that one either so i

think the best answer here because we're delivering in features or usable pieces that the customer can use let's go with answer c answer c an incremental project life cycle or way of work delivers small increments that a customer can use immediately gain value from and provide feedback on alright great stuff guys we are getting through the questions well done you're working with your agile team to size story cards and place them in upcoming iterations you notice that the points allocated to the story cards are getting bigger and bigger with each release why might this be

happening oh this is a good one okay the product owner keeps adding scope to the project no because we will prioritize that or the product owner will prioritize that maybe something if we've got a backlog here maybe something will need to drop off uh so or maybe we want to bring something in but something else has to come out so that's why we prioritize well um let's see what else we've got technical debt is being built on from previous releases that's very promising so if we're if we're just simply getting items developed quickly without looking

at the overall solution maybe we're building on technical debt so we're doing hacky solutions that require us to do more work in the future to fix up those you know those quick solutions so that's where i think that's where we could be getting bigger and bigger story cards or points on our cards team members are not working they're full a lot of hours that's not really something that we need to monitor we should be adjusting on the fly for our iteration so and that won't affect the actual story points themselves so that's a fixed amount

and then the effort that we take is different to that team members are working too hard and being burnt out that's i mean that's valid as well we don't want our team members to be working too hard and burning out we want a consistent pace of work a flow of work but that doesn't relate to the story points either so i think for our purposes let's go with answer b answer b agile accommodates for changing scope and should find a regular rhythm of velocity ruling out a and d the best answer is technical debt where

code may be rushed to production without being simplified or refactored with each subsequent release it creates more and more work to build on around this disorganized code and that's a really good way to put it so that's why we need to regularly refactor and we can build in slack into our t into our sprint so maybe we put a card with say five points on it maybe and we say that's a card for refactoring or refactoring some of the code or streamlining some of the code and then if something really high priority comes up then

we can take that card out and put the put the high priority card in but that's building in slack and slack that's like helps us refactor the code if we need to over time so that's a way that we can do that within our iterations and within our team all right that's really great well done guys let's see what the next question is the project sponsor of your agile team is quite familiar with lean and agile terms and methods she's asked you for the average cycle time and the average lead time for the project so

far what will you give her okay the average time for team leave and team attendance no that's not it that's just what they are team leave in team attendance time to complete stand-ups and time to complete retrospectives no not necessarily for lead time and cycle time we're talking about the work usually so let's see the average time to complete story cards and the time to complete features that looks very promising let's see what the last one is the average team downtime and the average time to complete releases okay out of all of these i like

answer c the best and here's why cycle time and lead time cycle time is the time for smaller uh increments basically so that would be our story cards and lead time is usually the lead time for something overall and so the lead time would be an overall feature for example so there's our lead time our cycle time and our lead time so because of that let's try answer c there it is cycle time is the time for shorter tasks most often story cards in an agile environment these story cards all combine to make up a

feature and lead time measures that time to complete a feature from beginning to end so that's a very good thing to know and that's one of our lean terms that you may come across as well even in your career just as you go through your career in project management all right well done guys getting through it you're going over the velocity of your agile team and notice it has increased over the past two iterations what might be the reason for this the productivity of one team member has increased that's quite promising the team no longer

tests each card no definitely not that we still want to test each card of course the team estimated the story cards more accurately uh i don't think that will that will impact the velocity increasing although it it might have an impact on it but not not directly the product owner removed some features from the backlog of work that won't impact our velocity increasing either that's just the work so velocity is how much we're completing each sprint so i think potentially if one team member increases their productivity then that will lift up the whole team and

the whole team's velocity as well so let's go with answer a answer a velocity and throughput are similar concepts typically velocity is the work completed by the entire team but obviously if the team is made up of people and if one person's velocity one team member's productivity increases then that will affect everyone all right well done guys doing great okay you're an agile project manager working with your agile team and talking through the defects raised on the project so far to get a more accurate view of effort per card you ask the quality tester to

begin tracking the defect cycle time what will they report back on okay and now we know cycle time and lead time as well so cycle time for a defect might be the time from start to completion of that defect so to to the time that we fix it so let's have a look and see what we've got how many defects were discovered no how long it took to fix a defect from the time it was found to the time it was fixed that looks very promising i like that one how many cycles it takes to

raise a defect no not that one uh that's i don't that's not necessarily you know the right words uh how many cycles no one really knows what that means the the number of features in the backlog that have experienced defects that's just counting the number of defects so it's not that one either for a cycle time let's go with answer b there it is cycle time is the measure of time for a smaller increment often a story card from start to finish but it could be for our defect or our bug as well so that's

a really really good thing to know yeah and that was well done well done guys let's go on to the next question you are checking in with the quality tester in your agile team and they advise you that there are a number of escaped defects in the most recently completed feature what are they referring to escaped defects these are ones that uh that get away from us they have escaped but also when they escape from us as the development team where do they go they make it into production so into the live environment or into

the working customer environment so that's probably what we're talking about here let's see what what uh information we've got a feature that was not completed by the end of the iteration no this is more about defects code that needs to be refactored that's more about refactoring defects the defects that have made it through testing and quality assurance yes probably that one and they will most likely make it into the customers hands which is what we don't want lastly team members who did not attend the daily stand up no it's not that one either that's more

about our team members so for defects and for escapes defects making it into our customers hands let's go with answer c there it is defects that make it through testing and release are called escaped defects and the cost and risk increases for these defects the closer they are to the live environment if if our customers are experiencing these defects then that could have a huge potential cost as our customers may not come back or they may experience difficulties or there might be you know risk or security you know i.t security risks there as well if

something is not developed in the way that they needed it so that's quite important but these are the most expensive type of defects to fix all right well done guys last two questions agile approaches emphasize servant leadership to empower teams servant leadership is the practice of leading through service to the team understanding and addressing the needs and development of the team members to enable the highest performance possible servant leaders approach project work in this order oh and it surely it has to be people first but let's see what we've got oh purpose that's also good

purpose people and process that's actually quite good so servant leadership as you know people it centers around people but we also want to start with why so from the classic book simon sinek start with why uh you know that's a great way to help motivate and give a vision for our team but also then how do we pull that off so maybe that's where the process comes into it so i really like that one but let's see what else we've got people's systems in technology we want to be more around people i think and growing

people so not that one information reporting and process similar deal there plant people and machine and again not really that one as well so i think the best one that we can see here from a servant leadership perspective is answer a there we go a servant leader approaches work starting with the why the purpose behind the work and then grows with works with growing and developing people and finally ensures a solid process for making that work happen and all of those three things are so important and it's just the different levels it's a high level

vision then it's you know working with the people who make up that vision and do the work and then the process right at the very ground level what is the day-to-day process for making that vision happen and that is the quality of a good servant leader all right last question guys well done let's see what we've got you've been part of an agile team for some time and working on the aspects of servant leadership to improve the results in your team what is not one of the characteristics of a servant leader oh good i love

these servant leadership questions uh really my favorite way to lead a team and to be to be in a team where there is solid servant leadership is just so much better as well so coaching versus controlling yes we want that promoting safety yes psychological safety can people can people speak up without fear of being reprimanded so this is really important promoting the energy and intelligence of others absolutely we want to promote the energy of people so that they can come up with solutions to the problems that we need and ensuring the team does what you

say no not necessarily as an agile leader you can facilitate discussion with the team but the team needs to provide all of that input and they're the experts so we want to rely on their expertise and that's the beauty of agile so let's go with the incorrect answer being answer d answer d the servant leader in agile coaches the team promoting psychological safety and trust and the intelligence and energy of others the approach does not include include directive leadership or forcing others to do what you say and we made it you made it that's 10

questions and you're preparing in an amazing way for your pmp or your agile certified practitioner exam you have delivered half of the features in your backlog for your agile project oh this looks like a scenario based question which is exactly the type of style that you'll see on the exam so this is really good you've noticed there's quite a difference in the number of defects over the last three iterations okay so defects and you ask the team to investigate both the common cause and the special cause variation what will they investigate so we've got defects

coming out and we want to investigate the variation basically between common cause and special cause so you might see this come up from an agile terminology point of view it's actually a lean terminology as well but let's see what we've got here issues that arose from normal operations and issues that arose from a unique or new condition now this one looks really good already because common cores are our common operations so our bau our normal operations and special cores uh things that uh that are coming out of left field so it's a special condition it's

a it's a it's a new condition so that is exactly how this one is described i think this is probably going to be our best bet but let's see what else we've got issues caused by the common area and issues caused by the special software no issues found in the last release and issues found in this release no again and issues caused by continuous integration and issues caused by no integration and again these things don't uh to me don't match up at all so it's as long as you know a little bit about uh variation

in their common cause and special cause then i think we'll be pretty safe here let's go with answer a and there it is variation in lean or the toyota production system is separated into common cause which is normal operations special cause which is special or new factors well that was a nice one to start with all right let's get into the next question and see how we go you have built an experienced agile team and have delivered constantly for your organization the product owner who has been with you since the beginning has taken another job

and new teammate a new teammate joins the team one with very little experience oh yes and and look this will definitely happen to you in your career people will come and go on your projects because projects themselves are temporary as well and so you'll see new people come on sometimes people who are not experienced enough this is a really good question so which of the below will you not tell them regarding the product owner role and this is also important because as a project leader you may need to guide people in their roles and maybe

sometimes you know because egos are involved you can't specifically tell them what to do but you can guide them and help shape their role and nudge them in in that direction as well as a true servant leader so i mean this is such a great question let's see what we've got here product owner role what won't we tell them okay the product owner represents the customer and generates maintains and prioritizes the backlog definitely this and to ensure the highest business value without creating waste well i mean that sums up the product owner really well and

if only all product owners were like this the world would probably be a happier place we may even have world peace who knows but definitely that is a good one the product owner must have a previous experience in agile to work in the team okay so this one stands out for me already because as we know the product owner needs to be an expert in the business domain or the customer domain that they're working in or that we're delivering to but they don't have to have previous experience in agile that can be coached and taught

and we can bring them into the team in the ceremonies for that to happen so i like that one as the standout one here let's see what else we've got the product owner may work with stakeholders customers and the teams to define the pro product direction and rank the work based on business value yes yes yes business value prioritizing all product owner things product owners typically have a business background and bring deep subject matter expertise to their decisions definitely yes for that one as well let's go with the correct incorrect answer being b there it

is the product owner role represents the customer or the area gaining the benefit so where we're delivering that value to because of this they often have that deep expertise in that particular area how did you go let's get into another question the intent of agile unified process is to perform more iterative cycles across seven key disciplines and incorporate the associated feedback before formal delivery okay so i like this because we've got it's an agile it's a it's an extra framework an auxiliary framework so you'll see lots of different frameworks i think there are there are

more than 40 different uh types of agile frameworks out there with different names and varying degrees of agileness but one thing that they have all in common are the the agile principles that you'll see like iterations delivering in increments uh of features of value getting feedback from our customers directly working with our customers directly and servant leadership and those sorts of things so we can use that as a guide for what this uh what this question is going to be uh iterative cycles i already like that getting feedback as you can see these are all

agile principles so this will carry across into our normal question which of the following is not a principle that guides aup disciplines so we don't have to know aup specifically let's have a look tailoring the approach to fit okay definitely a maybe for that one and for your pmp we want to tailor our approach all the time because every approach will not fit so we might need a little bit of agile we might need a little bit of waterfall if depending on the risk factors or the changeability of of the project itself so very important

we will need to tailor in our project ensuring the team knows what it is doing yes probably very important not really an agile process specifically but i'll give that a maybe as well collective agreement of scope before delivery oh gosh these are actually pretty tough uh and focus on a high value activities okay definitely that one so i love that one but we're looking for something that's not agile okay or an agile unified process collective agreement of scope that's the only one that really stands out for me because believe it or not we everyone doesn't

have to agree but we do have to we do have to basically talk about it and discuss it especially for scope it's more up to the product owner role so i think as long as we've got product owner arranging that scope and this is before delivery the team is there to deliver ah gosh this is a tough one but i'm probably going to say the standout is answer c here okay good so the principles of agile unified process also match those of agile in general you may tailor your approach absolutely to fit the situation using

some or all of agile methods the team must know what it's doing often with generalizing specialists okay that does make sense so generalizing specialist is our t-shaped person where we have a broad range of knowledge for a like a person has a broad range of knowledge but one deep specialty so they might be a developer for example but they might have a little bit of design they might have a little bit of you know business analyst work or requirements gathering work as well so they have a broad range at the same time such a powerful

person to have in your team whether it's agile or not and of course we're grooming the backlog and focusing on the activities that deliver the most value first all right that was a very tough one i'm glad we did that let's check out the next question the 12 clarifying principles in agile were defined to give more clarity to the agile manifesto and core values which of the following is one of the 12 clarifying principles i love these questions because this is the foundation of agile if you understand these then you have and exactly exactly as

we saw before these clarifying principles feed into all of the uh auxiliary approaches whether they're you know extra agile approaches or the core agile approaches like scrum kanban and extreme programming for example let's see what we've got here which one is one of our core principles 12 principles our highest priority is to satisfy the customer i already like that because we're working with the customer through early and continuous delivery i love that because we're delivering often that's what we want of valuable software yeah absolutely and the thing is agile you know it's expanded outside of

software now because it's become so valuable so it doesn't have to be just software but i really like this one let's see what else we've got the highest priority is to ensure executive buy-in by delivering high-value items high value items yes executive buy-in is definitely important but it's not part of the agile manifesto or the agile clarifying principles it's more about the team and conversations and collaboration with the team our highest priority is to reduce the impact of change by keeping information to a minimum no it's actually the opposite we want lots of information we

want transparency and we actually want to be okay with change and being able to change fast so not that one either and our high priority is to plan thoroughly and execute with discipline execute with discipline yes absolutely but to plan thoroughly while we do have a plan yes when we're planning thoroughly that's more of a waterfall or a predictive life cycle approach so i think the correct answer here is going to be a agile focuses on early and continuous delivery of value most often in a software environment but not always any knowledge work it says

yes and that's exactly it so you know it may not fit in an industrial environment necessarily but anywhere the work is hidden from view it's knowledge work it's uh it's not necessarily in plain sight very useful to use agile that was a great question let's get into the next one you are working with a new agile team and have reviewed the team velocity over the past three iterations the maximum number of points completed was 35 and the fewest was 25. what will you do next okay so 35 25 hmm what is this going to ask

what will we do next so push the team to complete 5 more than the maximum and roll over any complete incomplete cards to the next iteration so yeah look you will see this happen in your career uh just so that you know basically you will have a stakeholder or someone you know usually someone not super familiar or not within the team itself who will try and push the team to do more than the maximum amount that they have completed previously but that goes against the agile principle of continuous like having a continuous pace of delivery

a sustainable pace because what happens when we push the team they burn out and then people take sick days and it has the opposite effect so it's actually bad but most people don't realize this because it takes a while to happen so this is so important but anyway all of that to say that's not the right answer for us at the moment set 35 as the work in progress wip limit and adjust it during future iterations if the team is able to pull more work inside absolutely so this one we set the limit at the

maximum that we have achieved and so no more than that currently we we pull in the work for our iteration at 35 no more than 35 and then if the team gets through it all then they can pull more work so this is probably one of the better ways to do it and it's accurate because it's based on previous iterations and what we have previously achieved so really really important add more people to the team to complete the work because 35 is not enough we actually want small teams so adding more people may not do

it adding more people complicates the process it makes more communication channels it has more areas where things can go wrong it has more areas of conflict so we actually that may not work necessarily sometimes that doesn't equate to more work being done just adding more people reduce the number of features in the backlog to suit the team velocity not necessarily again we can we can prioritize the features in the backlog and have a high priority first but we don't necessarily need to reduce them and but in the sprint backlog they do need to meet our

maximum velocity which is 35 so let's go with answer b and there it is and to be agile works on continuous sustainable delivery exactly as we said pushing the team beyond their known limits is not a part of agile practice once the velocity is known it's good practice to set a work in progress limit for future iterations so as not to over burden the team and this is such an important concept not overburdening the team helping that engagement by you know not cracking the whip but actually helping everyone achieve the things that we all want

to achieve as a team and working together it's a sounds like a utopia and sometimes it can be when you get it right and of course there's going to be lots of curly situations in your actual career that will try and throw it off off kilter so that's good to know as well all right that was a fun one wow i really loved that question all right let's get into the next one you're the product owner in an agile team and have a list of features in a backlog that need to be developed each feature

is assigned a dollar value representing the return on investment now that is great that's you know that's a good sign of a good product owner you would like it to be risk adjusted a backlog so what will you do next note the risk impacts in dollars against the return in dollars then re-prioritize the backlog let's see what else we've got adjust the backlog to focus on the largest features first not necessarily capture known risks for each feature and then place cards to control those risks and prioritize in the backlog that one's also a really really

good one and that's actually exactly what we want to do as an agile team we want to that's how we can prioritize is by creating cards for the risks and then prioritizing those in the backlog so that way we do become a risk adjusted so there's two ways we can do this so this is actually quite tricky but you know in practice probably what we're going to do is raise our risk cards and prioritize the risks closer to the start of our project so that we're getting rid of those risks straight away and that's really

really important because the longer a project goes on the more those risks will cost us to to fix especially when they get to production so oh gosh even though this it could be could be the first one could be answer c and lastly create a risk register for the project and have it signed off by the risk owners that one's more of a waterfall approach so it's definitely not that one so in practice let's raise a card and prioritize that against our other cards and that's our risk card and that way it's risk adjusted let's

go with answer c all right this was quite tricky so you know i really really liked this and there you know there are definitely different ways to do this so the risk adjusted backlog is in a sprint is or release is containing risk response tasks for actionable risks these will be prioritized against the normal features also in the backlog to adjust for risk so now it becomes a risk-adjusted backlog wow i'm glad we did that one because that was quite tricky well done guys let's see what we've got next you're an agile project manager it's

analyzing the risk for each feature in your backlog by assigning a probability and an impact score to each risk oh so we're getting into risk now in a big way then multiplying them to calculate risk severity this is a traditional approach to risk and it's a wonderful approach to risk you'll see this in agile as well and you can when we raise our risk cards as we saw you'll have a probability and an impact multiply those together maybe it's uh maybe it's out of five and you say probability is five impacts five now you have

25 and varying degrees of 25 so you know if it's two and two for example you might have a card of four as an as an overall risk so that's the way we like to do that quite an easy way to do it and manage your risks how will the team handle items with the highest risk oh and this is exactly as we said we put those highest risk items to the front and do them as soon as we can because it costs us way more to do as the project gets closer to completion so

is there anything like that in here place yeah here we go place all the high risk items oh no no not that one uh schedule here we go schedule them earlier in the project to reduce that risk impact over time love that one we don't want a risk iteration we don't necessarily just want one iteration doing risk cards we want to be delivering value the whole time that's still important schedule them later definitely not because it's going to cost us more as we said and change the requirements to reduce or to remove the risk again

maybe you know not the best option because we actually might want those requirements they're still important to us we need to manage the risk not just remove those requirements so let's go with answer c answer c risk is highest early in the project before items have been completed by completing the high risk items first you're significantly reducing those risks and the threat of unknowns later on in the project what a great way to do it all right only a couple of questions to go you're doing great let's get into the next one the scrum master

tells you that agile builds problem solving into its process in a number of ways using transparency tools or yes and ceremonies which of the following is not something that's designed to reveal and solve problems and this is part of the beauty of using agile is we're transparent we reveal problems as soon as we can we raise blockers instead of waiting three days for an email we collaborate together and we talk closely as a team let's see what we've got retrospectives love that writing user stories possibly yes uh that let's see what else we've got iteration

demonstrations and reviews yes because we're demonstrating the product and the customer might say oh that's now that i see it that's actually not what i want oh no but that's revealing a problem and that's good so we want that raising blockers in the daily stand up absolutely we love that one retrospective's definitely that one as well because we're actually asking what went wrong or you know and what still puzzles me and we're deliberately answering those questions as a team so even though writing user stories i will say this when you're writing a user story usually

it's done with uh with your business analyst or your product owner and a developer and so the product owner represents the business and the developer represents the solution and so in in getting together and writing those user stories then that can actually reveal problems and you know sometimes before they occur so i will just say that that's that's still useful it still reveals problems but maybe that's not our best answer here let's go with answer b okay retrospectives sprint reviews and daily stand-ups all serve to reveal and solve problems that arise during product delivery writing

user stories is a useful task but is not itself designed for revealing so we're not specifically asking you know what went wrong how can we help how can we remove blockers but it is still a good practice and still useful for removing blockers and revealing problems all right great one okay next two questions last two questions you've done amazing work let's keep going you're nearly there the whole team approach and i love the whole team approach i think when you get to know it you will also love it because it brings everyone that we need

for our project within the team so we can talk closely and have quick answers instead of having to go out to other departments and you know having to get their time and costing money and taking you know two weeks for them to get back to us really really important it's an important part of creating the right cross-functional team the team facilitator is a key member within the whole team what is not correct regarding the team facilitator role and the team facilitator role is our scrum master or our agile coach or our agile you know servant

leader or our agile project manager many different names but the team facilitator servant leader is that role alright so the team facilitator or servant leader can be called here we go exactly as we said can be called project manager scrum master project lead team coach or portfolio manager well there we go i uh we we answered our own question there so that's definitely correct the team facilitator must have a degree in business incorrect the team facilitator is role is to facilitate discussion and elicit all those beautiful responses and collaboration within the team so you don't

actually need a degree to do that surprisingly and sometimes just self-learning can can be enough there as well all team members all team all agile teams need servant leadership on the team yes absolutely and every team member can actually demonstrate those values too team members should build up their own servant leadership skills of facilitation coaching and removing blockers that is also true so we don't want to leave this just to one person we want everyone to be involved and to be uh to embody those servant leadership qualities so our incorrect answer for this one is

b answer b the team facilitator role or scrum master uh yes so it's exactly as we said can also be performed by anyone the team though and that's really important to note if there is no specific role for it you don't need a degree but you do need to remove blockers and facilitate problem solving and that's so great and we're on to the last question which is also so great let's get into it you're rearranging a current agile team and you know that agile teams are cross-functional what sort of team members will you select as

you rearrange the team can you remember from what we've spoken about in our session today yes you can you already know it's a special kind of shape and it looks like this and uh let's see if there's any answers that match this and it looks like there is generalizing specialists with one focus specialty a t-shaped person one deep specialty and a wide range of experience in other skills that's definitely our answer there what else have we got team leaders uh with a specialty in leadership so everyone can lead yeah i mean not necessarily we do

want everyone to lead quality is everyone's responsibility but you know that's not necessary risk specialists yes we might need them but you know again they're not we don't want all of our team members to be risk specialists necessarily and don't add team members you should shrink the team i mean yes but also not always for that one so yes extreme programming says we should have shrinking teams because our teams are getting better over time naturally but look in practice that's very difficult and uh yeah and it may not always be correct anyway let's go with

answer a an agile team is made up of generalizing specialists or t-shaped people exactly as we've said and that's exactly you know that's exactly it and that's the last question i hope you guys have had a great time i've really enjoyed myself doing these agile questions and i truly believe that you can pass the exam and improve your agile skills through doing these questions i really do believe that you can do it you are helping the organization set up a new agile team and making sure they consider the whole team approach what is not correct

when regarding the whole team approach all right and this is where we get everyone that we need for our project within our own team instead of having to go to other teams and waste time and trying to get responses from other areas so this is a really good way to do agile the whole team approach means involving everyone with the knowledge and the skills is necessary to ensure project success well that pretty much answers that one doesn't it let's see what else we've got the team should be relatively small as the whole team successful teams

have been observed with as few as three people and as many as none that's a correct statement um but not necessary oh okay so for the whole team approach without our agile team yes we're looking for what's not correct i guess so that can be correct as well teams are often 100 to get dedicated to delivery because when switching or multitasking people make more mistakes this is context switching and people experience between 20 and 40 loss of productivity so this has been proven through studies in multitasking that it's actually not more productive and that's why

we have everyone in the one team so this is a really important thing as well so last one teams should not be multi-skilled as this can distract from the clarity of the role okay and that's incorrect because in the whole team approach we want our generalizing specialists or t-shaped people with a wide range of knowledge but also one deep specialty area and that's our cross-functional person so the incorrect answer here is answer d the whole team approach ensures that team members are multi-skilled and have at least one deep specialty that was really good all right

let's get into the next question you're having trouble selecting team members for your new agile team in a new organization what is not true about the cross-functional team member in the whole team approach and this is so great if you are hiring this is a good thing to know it's exactly we always looking out for the person with a wide range and a deep specialty at the same time cross-functional teams consist of team members with all the skills necessary to produce a working product that's true we want that everyone can be in the one team

teams do not need to use visual management because they're already good at what they do incorrect we still want to use the agile practices visual management like a kanban board and a burn down chart and team velocity chart we still want all of those things so that's incorrect that's probably going to be our guy there in software development cross-functional teams are comprised of designers developers testers and any other required roles yes very true cross-functional team members are critical because they can deliver finished work in the shortest possible time with higher quality but most importantly without

external dependencies so that's also true so the incorrect answer for our purposes here is answer b and there it is agile teams use visual management no matter how good they are methods like kanban stand-ups uh retrospectives burn down charts are used to increase better team working regardless of skill and that's absolutely true that's a really good question to start off as well let's get into the next one we're doing great there are three main types of role in an agile team the team includes representatives for the product owner cross-functional team members and the team not

creator not runner not necessarily enabler although that's part of what their role is we're removing blockers that sort of enables the team but mostly the team facilitator or agile coach or scrum master or agile project manager or anything that you want to call them they facilitate problem solving and discussion within the team let's go with answer b the team facilitator also known as here we go also known as scrum master team coach iteration manager project manager servant leader or any other agile name there their role is to help raise and remove blockers for the team

ensure an active flow of work very important and problem solve with the team when needed and this role because of that even though you know it may seem like an extra role it's extremely important helps that flow of work and removes those blockers really really great all right good one let's get into the next question we are flying through them today amazing stuff all right you are working through the iteration with your agile team and are having some trouble completing one of the story cards in the spring it is dependent on something else being done

and the contact is a way what will you do next okay uh so the contacts away and the so and we need something to be done raise a blocker at the next daily stand up so the team can swarm around the problem and solve it quickly uh yeah wow i really love that and that shows the power of agile because we can raise that blocker the team can swarm around it and problem solve and we don't may not need that contact to be here so that's actually quite good bring the piece of work in-house so

you don't have to worry anymore wow that's also pretty good but maybe not the most immediate answer may not always be possible it also does meet the whole team approach though which is good ask the product owner to remove that feature for now you can revisit it later uh ideally no like that's not the ideal situation here we still want to prioritize value based on its product normal priority and add cost to the budget and find a third party to complete the work definitely that would be the last preference there even though you might do

it definitely not not our first way to go so i think uh you know like that one's a maybe but i think raising the blocker is definitely where people can swarm around the problem that's probably going to be our best bet let's go with answer a problem solving is done with the agile team blockers are raised as soon as possible at least once a day during the daily stand-up so the team can swarm around the problem get help for any experts needed and then move on and that's a great way to do it all right

good stuff next question for us we are up to number five doing great the product owner representing the business on your agile project is used to a more dictatorship style of leadership so they're telling people what to do specifically you explain that servant leadership is used in agile to ensure a safe and open environment why is this important to product development and this is so important to product development it's so the agile team lead knows who to blame no when things go wrong we're not blaming people what we're trying to do is remove blockers so

people can do their best work that's our main thing so the team can accurately count the defects no not necessarily they should be available for everyone to see anyway as well so the team feels free to ask for help admit to problems or failures and to improve yes that's exactly it if we have a dictatorship style of leadership um you know getting getting down on people when they make a mistake then what's going to happen they're going to stop telling people about their mistakes and what's going to happen those mistakes are going to be hidden

and then we're going to find them when we release the product and it's you know going to be a much worse experience for everyone involved we want transparency we need people to be open and we need the environment to be safe so people can be open and last one so the entire entire team can push work on on each other if they know they have time again not necessarily uh we have the kanban board so everyone can see where the work is and it's transparent as well so i think the correct answer for us is

answer c psychological safety is one of the most important parts of a high functioning team and this is so true which means having the safety to be vulnerable admit to problems ask for help and improve it starts with the leader and servant leadership contributes to this uh and that's just a great way to put it so yeah a really good question for us all right let's get into the next one feedback in many different forms is one of the most important parts of a successful agile product delivery which of the below is an agile method

for gathering and using feedback to improve oh this is good and agile is all about feedback and also about improving so this should be fairly easy let's see how we go having a once weekly working group meeting no we want daily meetings we want more collaboration we want more communication so not one once a week is not enough for us conducting sprint reviews or demonstrations that include all stakeholders yes because that's gathering feedback on the working increment or the feature and it's we're using it and the stakeholders can say oh yes this is exactly what

we wanted thank you very much or oh i didn't think this did you know something is wrong here so we're getting feedback sending out project reports to project stakeholders to view no i mean that's that's a report but it's not necessarily getting feedback isn't so not that one asking stakeholders for feedback only when development is blocked uh no not again we want feedback all the time just to make sure we're always checking in to make sure that things are on track so the correct answer for us i think is answer b demonstrating the usable increment

developed during an iteration to the customer or product owner ensures feedback is gathered more quickly than only at the end of a project and retrospectives are another way to do it so that's really good to know as well all right great job guys only three questions to go i think three or four i mean we're doing so great so really well done uh and you know this is great practice so keep going you're working on an agile project where the product business representative is pushing for more and more features to be delivered in each iteration

you know what they are asking is not possible based on your team's current velocity what will you do next oh this is a great question this is a great uh you know scenario-based question and you might see this in the real world too so let's see what we've got show them the team velocity and the points allotted to the cards in the backlog and then ask them to prioritize the features at the next sprint planning yes yes yes this gives the business representative control so they have control over what's delivered however it's within certain boundaries

so it's just a beautiful way to do it we're saying we can deliver this much but you have control over what is actually delivered what is the highest value to you wonderful way to do it i think that's going to be our answer add more members no ask for another business representative who understands the technology better sometimes that would be nice but we don't you know that's not the way we want to educate and work within a beautiful system that actually works which is agile remove some of the features yourself and see if anyone notices

oh yes wouldn't we love to do that sometimes but maybe not the best answer for us so let's go with answer a an agile team ultimately serves the customer exactly right and in many cases the customer is the business or the business owner or the representative who we're delivering value to um so who are we delivering this value to if they're not also the product owner and familiar with that way of work then you should show them the team velocity versus how many points are allotted and ask them to prioritize based on that and this

gives them control and makes everyone feel a lot better about what's happening so i think it's a wonderful way to do it as we've seen great question that one let's get into the next one you're working on a traditional waterfall project oh yes and the organization wants to move to an agile way of work or even better the functional manager wants to get the benefit of certain agile tools that they've heard about to you to uncover potential problems before they occur what will you do next okay we know the things here visual management um you

know asking for feedback and all of these things that we've spoken about write the change into your project management plan and circulate it with project stakeholders not really agile no set a weekly working group meeting to discuss the project not really agile as well iteration planning maybe but just jumping straight into iteration planning will probably scare a lot of people so that might not be the best make the product backlog iteration kanban board and velocity chart all visible in a co-located team area i think that's probably the best answer and these things can really integrate

with a normal project quite seamlessly you can have a kanban board with the cards on the board you can have a velocity chart to see how much work is going through the team on a fortnightly basis or per sprint and you can have the product backlog which is what we're wanting to deliver the features the tasks so all of that is still possible even in a waterfall environment and i've seen this happen many many times it's a hybrid approach and you'll see this on the exam as well so let's go with answer d there are

many agile tools to detect and prevent problems visual management is our best tool here kanban board so visible backlog and velocity chart everyone can see what the team is up to if things are going off course we can also see that as well if there are any blockers we can also see that and putting it in a co-located place having daily stand-ups team iteration planning before our iteration putting those features according to the prioritized business value retrospectives demos and reviews all of these things are designed to uncover problems and solve them early and that's part

of the power of an agile way of work all right last two questions guys well done we've got the agile manifesto has 12 clarifying principles added to it to help projects and teams understand the agile values which of the below is a correct clarifying principle tailor and approach taylor the project approach to suit the project and the team yes i love that one ensure executive buy-in not necessarily so we can make managers and executives part of the team by inviting them to our daily stand-up inviting them to our demos and reviews inviting them to our

retrospectives if we really really want to we're transparent enough and where you know let's share the information so that they have that access to that information quickly as well deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter time scale right this is about the 12 clarifying principles i forgot yes so i didn't read the question correctly but this is exactly one of our 12 clarifying principles so you've got the agile manifesto and you know which is people interactions over processes and tools and stuff like

that and this is our 12 clarifying principles this is definitely it last one ensuring complete planning that's more of a waterfall approach so let's go with answer c deliver working software frequently from a couple of weeks to a couple of months and that's one of our agile clarifying principles a great way to add more meat and more information to an agile approach really well done and also really well done is the last question which we're up to and you've done an amazing job here we are the agile oh and it's another clarifying this is great

now we get to get more information from the actual source this is a 12 clarifying principles what is a correct 12 uh clarifying principle here so business people should dictate to the development team what to do we don't want to dictate do we so we want servant leadership not the same as dictatorship style developers can code and release products at a schedule that suits them for complete autonomy also no because we may actually have items or schedules that we need to meet and that's why we time box everything two-week iterations you know spike cards for

researching things that we're uncertain of so that's it anyway that's a slight sidebar business people and developers mustn't work together no we want them to work together so that's not correct business people and developers must work together daily throughout the project and when this happens you will see a little bit of magic start to occur and the project will start to pick up speed engagement will start to increase this is one of the most powerful things that you can do and when you get it right and when it starts to happen wow that's when the

magic really happens let's go with answer d as you all know from the various agile approaches business people our product owner who represents the business or the customer they must work together with the developers daily throughout the project and that's a wonderful way to do it and also a wonderful way to do it is to practice your agile questions by going through these videos with me and spending a little bit of time through your day and preparing for your exam i think you've done an amazing job and i also truly believe that with this practice

and with your dedication you absolutely can pass these the exam and let's start off with something not too difficult we'll ease ourselves into it but this is such a wonderful way to do it it's a question on the clarifying principles of agile the absolute foundation but behind agile that will sort of feed into all of our questions going forward anyway the agile manifesto has 12 clarifying principles added to it to help projects and teams understand the agile values which of the below is a correct clarifying principle okay build projects around a core idea then brainstorm

frequently to get the job done that's not too bad but it doesn't 100 match we're not just brainstorming we're also delivering we need to deliver in increments as well so maybe not that find the right executive to support and ensure they tell you the product requirements the executive shouldn't be telling us the product requirements necessarily it should be the people who use the product or the system that's really important too deliver frequently whether an item has been tested or not no we do want to test it but equality is everyone's responsibility yes that is true

so when we're gathering requirements we want quality when we're developing when we're figuring out the solution yes we want to build in quality there as well and make sure it's a robust solution but part of that is still testing so that's really important too build projects around motivated individuals and give them the environment and support they need and trust them to get the job done well that's exactly the statement we trust them to to get the job done but we give them the environment and the support we remove blockers we give them the tools we

give them the agile methodology the regular stand-ups removing blockers you know getting the the customer involved in the work making sure that everyone is happy and getting feedback regularly and the motivated individuals these are the people who own the product or who use the product let's build our product around those guys get them involved and you know all of a sudden they actually really want to see this happen so they're making it happen and that's part of the power of agile the correct answer here is definitely d agile is about building projects around motivated individuals

with cross-functional or t-shaped people who have a broad range of expertise and one deep specialty and giving them the support they need to remove by removing blockers and ensuring a flow of work that was a really great one to start with all right the 12 clarifying principles also match up with the best advice for projects leadership and communication which of the below is a correct clarifying principle when it comes to project communication oh this is good too all right and you know again this is a really lovely way to just ease into our agile knowledge

here and get the foundational questions this is really good the most efficient and effective method of conveying information to and within a development team is face-to-face communication already we can say that that is definitely correct why is face-to-face communication the most important because one we get a fast answer we've got one person here one person here and we're just going back and forward we're getting the answers quickly now we're also picking up on extra nuances and that might be you know someone makes a face or you know someone you know is a little bit closed

off maybe they're not certain about something and so now we can delve a little bit deeper into that communication a lot of communication is non-verbal so that's really important and all of that is lost if we're just sending an email emails can easily be misinterpreted and that's why face-to-face in communication is so important i think that's going to be the one but let's see what else we've got communication is always done in writing no just just to make sure they have proof i mean but then all of that communication style is lost as we saw

so not that agile teams ensure downward communication only so the executive in charge directs the product features and the work again no we want the team to collaborate it's actually horizontal it's not downward it's not executives going down to their people it's people talking with people and getting all the work done amongst the team it's horizontal in that way we're not going up to executives necessarily we're not going down to anyone below us everyone is equal you know it sounds kind of nice doesn't it and it is when it works really well when communicating ensure

that various forms such as telephone writing face to face and ensure variety i mean yes variety is nice but still the best approach is face to face let's go with answer a an agile team knows that communicating close in person place and time is the most efficient and effective way often in a co-located team so other team members can pick up information by osmosis wow that's another important part if you've got lots of people around and these two people are talking then they actually pick up on that information as well so it's a triple bonus

you know so that's really good that's called you know osmosis picking it up without necessarily talking to those people directly really really powerful all right that was a great question let's see what else we've got the agile manifesto has 12 clarifying principles and here's another clarifying wow okay i'm pretty sure we move on from clarifying principles after this but let's get into this really quickly and we already know the right answer here as well so it's not union attendance we don't need a union to be involved working software is the primary measure of progress why

because we're delivering in increments and features and we're getting feedback on that every time from our customer a little there's supposed to be little loops there my terrible drawing but that's in that way we're delivering software working software on a regular basis that's definitely our one finding risks is the only way to avoid failure not true learning new things helps keep a team engaged sometimes true but not always necessarily true so let's go with answer b in an agile team working software or a working product increments and features delivered is the primary measure of progress

well done guys all right now we're starting to move on and this is going to be really good you're new to your agile project and the team are working through the forming stages how do you help the team improve as the project progresses okay and we know that there are a few stages of a team so we're forming um we're storming so that's when everyone is trying to figure out their you know where they fit who's what they're supposed to be doing what their role is you know where the boundaries of their work is norming

where we're starting to come together work as a team and performing that's when everyone has their ideas very clear we've sorted out all the rough spots and now we're starting to work as a well-oiled machine and so how can we how can we help the team improve so the ensure the team holds a project post-mortem and catches the lessons learned by the end of the project uh maybe but that's more at the end not during the forming stages isn't it so maybe not that one hold a retrospective with the whole team at the end of

each iteration and build those lessons it learned into each new iteration probably i like that one as well because now we're getting shorter feedback it's not at the end of the project it's at the end of each two-week iteration ask the product owner to show the team where they can improve no it has to be a whole team approach so the whole team has to be involved rotate tasks and roles during each iteration well if we do that then we're going to lose the expertise that someone might have on a particular area so not necessarily

that one either let's go with the correct one as answer b our classic retrospective using agile retrospectives at the end of iteration uh with the whole team to ask what went well what did not go well what did i learn what still puzzles me the lessons from this session are actioned and built back into future iterations to improve quickly a great way to do it well done guys all right let's get into the next question you are the agile project manager working through the product requirements for the product owner and executive project sponsor wow a

lot of people involved here and so this is going to be a good one the project sponsor raises concerns that the development team do not fully understand the requirements what will you do next and this can be a valid concern and you know this will happen all the time we can't be experts in everything so let's have a look and see what we want to do show them the project management plan which will have the scope statement listed in the scope baseline now we might do that for a waterfall project or a predictive style water

project that's our project management plan where we plan everything up front and we have a clear scope statement but then what happens when we start delivering is all these things start coming up that we didn't think about that's why agile works in that scenario ask the team to create a high level prototype of the requirements and then discuss and review that with all stakeholders that's definitely the answer we want to do a short increment and it's just doesn't have to be the real thing just an idea of it so it could be a storyboard it

could be a wireframe it could be a 3d prototype if you're dealing with you know actual physical items and and creating things but now once we can see that we can also discuss it and we can say oh yes that's correct oh yes now we say you know that we do understand the requirements maybe we need to talk them through but then we all come to a collective understanding so that's definitely the one i love that one show the team the project schedule outlining the delivery dates not related hold a retrospective to gather feedback and

improve could help but not really related again this is more for the scope and to get a shared understanding we want to see a small increment and then discuss that so let's go with answer b agile uses visual mock-ups or prototypes such as storyboards wireframes or models to get a quick understanding of requirements and consensus from everyone involved now that's a great way to do it all right well done we're halfway through you're doing great keep going the scrum master on your agile project has asked you for the total lead time of a particular feature

you add up the cycle time of all the cards that contributed to that feature and cycle time is the small parts the story cards usually and the lead time is the overall project so so all these stories lead into the project or the lead time for the for the whole project so cycle time and lead time and that's a great way to remember it and to look at it what other two factors must you take into consideration when calculating total lead time time for testing the code and time for merging the code meeting times and

lunch times not that value-added time and non-value-added time so what we're talking about with cycle time and lead time it's a lean concept and another lean concept is value-added time and non-value-added time so value-added is are we actually working on these stories that's value-added we're doing that we're developing those things non-valuated time is uh you know what's something maybe a blocker that's getting in the way maybe we're waiting uh this is where the lean wastes come into it so handoffs uh maybe we've got too too much work in progress and we're context switching uh maybe

you know there is uh there is waiting in between the tasks or waiting for an answer not getting fast answers all of these things um are a waste and that's non-valuated time so let's and testing and documenting you know we still need that so that could be seen as some essential non-value-added time even though it's not directly doing the story um we it's still essential so that's another thing anyway let's go with answer c lead time is a concept from lean and the toyota production system whenever you are calculating cycle time smaller things such as

story cards or an iteration in a larger project the lead time which is the larger items you must take into consideration both value-added and non-valuated times so evaluated contributes to the customer outcome non-valuated doesn't directly contribute to the customer outcome so that's really good to know wow that was a great question all right we've only got a couple to go let's get into them when working in an agile team it is common to use prototypes demonstrations and reviews wireframes and storyboards to elicit feedback from the customer or product owner what is the benefit of using

these tools oh this is another great question let's see what we've got so the development team don't have to create the real thing no we still need to do the work obviously so the team can get together and have another meeting i mean we don't really want more meetings but we do want more communication so you know not really the best answer there it allows the users to create new forms that will be required for the new system not really related it could be anything it doesn't have to just be forms it allows the product

owner to discuss and agree on requirements with their stakeholders and exactly as we saw before now we can see feel and touch this this prototype or this wireframe and we can discuss those things and come to an agreement i think answer d is the best one here prototypes wireframes and storyboards are important ways to gather feedback and that feedback allows all stakeholders to discuss and agree on the requirements and product features before the money is spent on actual development so that's really important too we get to test it out before we actually spend the big

bucks on developing it so that's really good all right great job guys keep going you're finishing up the first iteration of your agile project and have set a retrospective for the whole team one member of the team asks why we have this meeting if they and if they really need to go oh this and you know this will happen in your project career as well what will you tell them it's so important because we need that feedback so let's see what we've got it helps the team prioritize product features for the next iteration no that's

our iteration planning or our sprint planning so that's uh not our retrospective it allows the team to blame others when things go wrong we don't want to blame we want to remove blockers so that's a different thing it's an opportunity for the whole team to look at their way of work and improve yes we want the whole team to be involved because everyone might have different feedback and we need to take that on board and improve it showcases a part of the product so everyone can see what was delivered that's a demonstration or review a

sprint review so not that one either let's go with answer c retrospectives are a set meeting at the end of each sprint asking for feedback with certain questions what went well what didn't go well what did i learn and what still puzzles me the actions from these are built back into our process to continuously improve that's part of the power of agile alright last two questions you've done really well let's keep going you're in the beginning stages of a new project where the organization would like to use agile to manage the project work this is

great the executive manager asks you how the team will make quality everyone's responsibility as we know that's part of an agile approach leverage the various skill sets within the team and remove reliance on external inputs wow what agile method is she describing here and we've sort of been through this especially in the last couple of videos but how do we remove reliance on our external people well we've got a project over here we want to bring them into the team and that also helps make quality everyone's responsibility and leverage all of the skill sets within

our team without having to go externally and the way we do that is with servant leadership is good yes we do want that but it's not that sprint planning is a ceremony it's not that the daily stand up also a ceremony it's not that what we're talking about here is the whole team approach bringing people into the team to make sure we're self-sufficient and can deliver the product within our one team much easier reduces handoffs reduces silos it's a way better way to work so let's go with answer d the whole team approach aims to

bring all necessary people into the project team ideally in a co-located space it involves cross-functional team members who specialise in one skill and are fluent enough in a wide range of other skills so nice wide range of skills but one deep specialty and maybe that's design or development for example so yeah anyway that's the great way to do it that's the whole team approach and also a great way to do it is the last question for us let's see what we've got you're working in an agile project for some time and have been blocked by

the need for expertise in another team what do you do to overcome organizational silos well we just spoke about this so this should be pretty easy what will you do work with the various managers of team members you need to have them dedicate the necessary individuals to our cross-functional team we're bringing them within our team exactly as we saw i like that one so raise a change request for review by the project change control board as the work will be delayed that's an old school way to do it that's our waterfall methodology not that one

raise an issue in the issue log for review and management by the project team again an old-school way to do it for an agile way we want to bring them in we want to bring them into our whole team so not that one work with the risk team to raise a project risk and assign an owner to it and create controls for those risks again more of an old-school way to do it so for our purposes let's go with answer a this is describing the whole team approach which was spoken about where all the necessary

team members and their skills are brought in to the project team reducing silos reducing handoffs and making sure that we can deliver the project as one team and also what we've delivered is 10 questions today and i hope you've enjoyed yourself because i certainly have i love talking about agile and i know that you truly can pass your exam with the dedication and practice that you are putting in to these questions i truly believe that you can do it the 12 agile clarifying principles also match up with the best advice for workflow and getting things

done which of the below is a correct clarifying principle when it comes to project workflow can you pick the right one okay let's have a look agile does not use processes as it prefers individuals and interactions over processes and tools ah oh that's tough that's sort of correct because that's one of the agile manifesto core principles basically the core values but i don't think that's an actual it doesn't sound right let's see what else we've got here agile processors engage and support the team by ensuring sponsors developers and users all get what they want not

necessarily sometimes you can't always get what you want as the rolling stones said but if you try sometimes you just might find you get what you need and you know that's true in project land as it is anywhere else as well what else have we got here agile processes promote sustainable development oh gosh i love that sustainable development and that's what we're talking about isn't it where we can we can keep working at a sustainable pace so we're not burning out we're not being pushed you know beyond the velocity that we're able to complete so

this is really important um the sponsors developers and users should be able to maintain a constant pace indefinitely i love this one and you will see related questions around pace and velocity on the exam as well and knowing this is really important agile processes help as much work get done as possible when the team thinks they can't go further agile pushes them to go the extra mile not true so we have our velocity and you know that's how the average of how much we've completed over the last few sprints and we want to not really

go above that unless we've finished all of our work in an iteration if we push people too hard you know obviously we want people to do the work but if we push them too hard they burn out have sick days and become disengaged in the work and trust me it results in a little in less work getting done as well anyway let's go with answer c there we are agile provides promotes sustainable development be wary of often switching tasks or pushing for too much work during an iteration this will burn out individuals and ultimately will

slow down your progress really really important and a great question to start with all right let's see what we've got next the 12 agile clarifying principles also match up with the best quality advice for quality watch which of the below is a correct agile clarifying principle when it comes to project quality okay continuous flow ensures work is done at a reasonable pace and defects a court that's quite a possible one continuous flow is is really nice it's from the twitter production system but it may not you know it may not ensure that defects are caught

it's not really related so it it sort of makes sense but then when you look into it it doesn't really uh so let's see what else we've got testing is done at all levels from unit testing to end to end testing that's also a correct statement we do want that in an agile team but it's not a broad statement though it's more like into the nitty-gritty oh gosh this is a pretty tough one okay continuous attention to technical excellence and good design enhances quality that's also a correct statement so you know we definitely want that

as well but the probably the best one here is quality is everyone's responsibility in an agile team meaning everyone will test the product oh hang on that doesn't mean everyone will test the product either quality is everyone's responsibility but that actually just means that um you know from the card all the way through to creating the card through to developing the card through to testing the card through to signing off the card everyone has a hand in making sure that quality is is there so that's what that means more uh more importantly uh all right

so let's see which one we're going to choose if this one's a little bit off it doesn't quite match up testing is done at all levels um you know that's good but it's maybe too nitty-gritty for us here quality is everyone's responsibility is true but not everyone tests the product i think let's go with answer c where continuous attention to technical excellence for example our extreme programming principles and good design that enhances our quality let's see all right while some of these answers match up with the principles in general only uh the continuous attention to

technical excellence is a clarifying principle from this list did you pick it well that was a that was a tough one ah that was a great one to go through all right let's see what we've got next the 12 agile clarifying principles also match up with the best advice for keeping things simple in a project which of the below is a correct clarifying principle can you pick it simplicity let's see what we've got simplicity is only possible when the team first understands how complex the system is gosh that's a nice statement probably true let's see

what else we've got though simplicity is part of every project everyone naturally simplifies the work as part of their role i think that's in an ideal state but in reality simplicity is very hard it actually it's harder to create simplicity if you know what i mean it's harder to make things simple that's why we end up with workplaces that are complex and convoluted all the time because it's just easier you know it takes less effort to leave things in a complex state okay let's see what else we've got simplicity reduces cost in a project ensuring

executives are always simplifying the process and the system executives in my experience often complicate things unfortunately just because they're not in the nitty-gritty of the detail and you know it's a hard thing to be you know many levels above the work so you know i don't like that one either particularly simplicity the art of maximizing the amount of work not done is essential it's occam's razor where you know we want to make it as simple as possible but no simpler for example i think answer d is our absolute best bet here let's see there we

are that's our clarifying principle did you pick that one i think that was a good one and we've only got two to go so let's see what we've got the agile manifesto has 12 clarifying principles to help you understand the agile values they are also best practice on improving the team over time all right let's see this is this sounds good which of the below is a correct clarifying principle the team will meet daily to build a supportive network of workers yeah i mean the daily standup is a great way to check in it's wonderful

and also to remove blockers so that's nice but let's see what else we've got at regular intervals the team reflects on how to become more effective then tunes and adjusts its behavior accordingly and this is the iterative approach where we're iterating and continually improving and it's also the retrospective if you if you will notice that so at the end of each sprint or at regular intervals as it says here nice and high levels so it could meet any criteria or many different criteria i think that's probably our best bet for now features are regularly improved

through refactoring of the code that's actually a good one as well i really like that but not for our clarifying principle the project sponsor regularly swaps team member roles to keep everyone learning and growing that's not necessarily how we do it in an agile team we prefer pairing up together so can we pair can someone do the work can someone check the work and then vice versa and also can we you know the team members we want have a a wide range of expertise and one deep specialty so they might be a developer but they

might have a little bit of testing or they might have a bit of requirements for example or something similar all of that to say let's go with answer b there we are that's our correct principle and it becomes the team retrospective in practice so that's really good to know and also good to know is that we're up to the last question for this round and these clarifying principles can you pick the last one let's see what we've got all right which of the below is not an agile clarifying principle oh this is going to be

good okay our agile our highest priority is to satisfy the customer through early and continuous delivery of software what a beautiful way to do it definitely that's an agile clarifying principle we want to deliver more often if we can get things small increments in the hands of our customers so they can see feel and touch it or we can get the feedback that we need to adjust all right ensure delivery timelines are met at all costs in fact that's probably the one that we're going to call out here because with agile we might have scope

we might have cost and we might might have time and all most of those things are fixed except for scope is very flexible so your time might be fixed but we you know but that doesn't mean that we're meeting those delivery timelines because the scope is going to be different that's going to be prioritized by the product owner and the business and so it might the delivery might look different in other words uh the last two just so that we know welcome changing requirements even late in development absolutely agile processes harness change for the customer's

competitive advantage we may need to adjust we need to be open to that lastly deliver working software frequently from a couple of weeks to a couple of months with a preference to the shortest time scale so we can gather that feedback and those are the rest of our agile clarifying principles the one that we don't want is answer b and there it is how did you go did you pick it did you pick all of these agile clarifying principles if you did you're well on your way this is the foundation behind all of the questions

around agile on your exams for agile certified practitioner or the pmp or even the capm exams or any other related project management qualification as well you will see this sort of thing and i've really enjoyed spending this time with you going through these questions you are going through a retrospective with your team at the end of the sprint where the team have raised an issue that is slowing down their work the scrum master guides the team to go through an exercise called the five whys what is the purpose of this what's the purpose of the

five wise and this is a really good way for dealing with the issues that come up when you're doing your retrospective so is it to ask who what where and when to find the cause of the problem no we're asking why multiple times until we get to the root cause of the problem so to ask why the issue happened and then why for each reason after that until the cause is found that's definitely our one and this is from the lean uh from the lean method or the toyota production system uh which basically is where

a lot of the agile methods came from they use the five wires to problem solve and find the root cause the other ones that we've got to ask why the team is working on each feature to give the team purpose no it's more of a root cause thing so finding the real cause of an issue and to allocate the five wise uh to allocate five wires to each story card to ensure the team knows the reason for working on it uh no different not that one as well even though a story card should have the

why at the beginning that's a very good practice for your story cards we use this the five wires to problem solved so let's go with answer b answer b the five wise is a problem solving technique from lean or the toyota production system that asks why a problem occurred for each answer the team asks why again until they get to the real cause of the issue well done guys alright let's get into the next question the scrum master in an agile team has asked the team to do a self-assessment what is the focus of this

self-assessment how often the team meets during the week how many story cards the team have completed no that's for our velocity more likely how much yearly bonus the team should receive no that's not really related to agile at all and you know that might be just different for every company that you work in you will find that and how the team performs and delivers together yes that's the one that we're looking at and really you know it's a good way to check in with your team to ask a few questions around delivery and how we're

working together and just assess as an individual you know how they're feeling and you know it's a really good good practice to do and also a good way of getting feedback which is a great thing as a part of agile let's go with answer d the team self-assessment is used to gauge the team members performance together with results helping to identify what is working well and where improvements can be made the team then meets to problem solve improvements and celebrate what is working well that's a really good question all right let's get into the next

one you're working in an agile team and the business representative would like to get an idea of the risk associated with a particular feature what will you do next show the risk management plan from your project management plan to the business representative that's more of a waterfall approach probably with your risk management plan so let's see what else we've got ask the development team if they like the feature uh probably not specific around risk although getting development teams input is very important hold a premortem where each team member writes reasons they think the task or

feature might fail so these can be discussed yes this is an excellent answer and it's really just a risk brainstorming session um ins a post-mortem is at the end of a project where you discuss reasons that uh that things went wrong so we already know that they went wrong but this one is uh is brainstorming them in advance so where before these things might happen a pre-mortem pre you know mortem being death i think is the the word in latin or something similar uh so yeah why is something going wrong for example so i think

that's going to be our one check your gut feel for the feature and if it doesn't feel right look into it more deeply now let's go with answer c a pre-mortem looks at reasons for failure before they happen and is a great way to brainstorm for a card or feature typically feed our team members write their reasons down and discuss and around robin style as some people may come up with the same idea and then you know you can group those together in an affinity diagram for example so if you've got similar ideas group them

together one two three for example you know just other ways to do it all right doing really well guys just a couple of questions to go you're the agile team leader and are working through a team retrospective when an issue experienced by the team is raised what will you do next and we sort of touched on this before didn't we because what we want to do is get to the root cause of an issue so how do we do that do we perform fish bone analysis k no analysis canon analysis is more for value so

what's the customer value regression analysis is for trends so you know what's the trend in the data lots of data data points and what's the the line of best fit for example uh you know is it trending up is it trending down that sort of thing multi-vary chart analysis is more of a more of your your chart similar to a control chart it can be but with with variable uh inputs coming in and so you know that we could look at that but probably the best one for problem solving is our fish bone analysis also

called ishikawa diagram after the person who who founded this from the toyota production system again and that's where we have the problem at the head of the fish and then the fish bones one two three four and we have brainstorming buckets so do we have people do we have process do we have information that people are not getting and any issues with the system as well a pips is a good way to remember it people information process and system and we can brainstorm into those buckets reasons why these things are going wrong and it's a

really easy way to do it anyway all that to say let's go with answer a when an issue is raised the best course of action is to get to the root cause of the issue of the items presented fishbone or ishikawa diagram analysis is the best tool for root cause analysis all right very good let's get into the next question you've been hired to lead a new project team as an agile project manager you come on board to learn that the organization uses a hybrid model what does this mean and this you'll see this on

your pmp exam as well because a hybrid approach is a part waterfall but also part agile or other other methods like incremental or iterative for example so let's see what we've got here the team is a hybrid of developers designers and business users to get the best return on investment that sounds good but it's actually not the the idea behind a hybrid model the product you are developing will use both electricity and fuel for power like a hybrid car very funny uh yes not that one in particular hybrid we're looking at a different kind of

hybrid so let's see what else we've got a combination of predictive for example a project plan planned in advance and adaptive for example iterations backlogs can ban project methods will be used yes that sounds exactly what we're after exactly as we said a hybrid team environment of physical software physical and software reporting boards will be used again could get tripped up by that one but that's not the one it's not a physical or a software environment it's a hybrid uh combination of project management methods let's go with answer c there we are a hybrid project

management method means using predictive and adaptive methods predictive being your traditional waterfall approach pre-planned project plans scope plans quality schedule and risk adaptive approaches will be prioritized uh we'll add a prioritized backlog of features and a kanban board um maybe iteration planning maybe uh retrospectives uh all these things can be can be added to a waterf waterfall approach to make it a hybrid model all right there you go we've got a couple of questions to go let's get into them you're the product owner in an agile team working with the developers to create story cards

to place in the product backlog what other or in the three c's of user story creation what do you do first okay and we're creating a card uh i mean that actually could be the first thing so the three c's of user story creation uh so i mean that's a good tip for us if we're creating a user story um and then what do we do around creating a user story um usually there's confirmation for example uh and there's conversation and then there's maybe do is it creating let's have a look create the card which

is the physical or software driven media describing a user story that sounds promising to me let's see what else we've got confirm the acceptance criteria i think that would probably be last because we're confirming once everything you know once we've gathered all of those things together have a conversation with the team to flesh out those requirements i think that'll be number two because uh yeah that seems reasonable if we're creating the card having a conversation around it because agile prefers conversation to emails or to you know writing a letter or to you know even to

like ideally would pick up the phone or get face to face in conversation and get fast answers and last one catch defects before they're developed by working with quality testers before and after not really related and you know just a general process in itself separate to this so i think let's go with answer a for creating the card and there it is yes creating the card conversation with the product owner and developers to explain how the software or design will be used and confirming that acceptance criteria and the definition of done or against the definition

of done so that's a really good one wow that was great all right now we've only got two two questions to go and i hope you've enjoyed these because i've really enjoyed going through them let's see what we've got in the last two you're working on the product backlog with your agile project team and creating user stories to be prioritized which of the below is the best answer for what should go into a user story card okay great and use a story card as we know we want the requirements and maybe you know an idea

of the solution um and so let's see if anything matches up with that okay key risks of the project and the featured being developed developed with their owners and mitigations that's more around the risk log for example or if there is a if we're raising risk cards in agile so maybe not that one specifically a wireframe of the feature to be developed that developers can work with that's a good idea wireframes but you may not use it in every story card so what is the best answer for what should go into a user story card

let's see what else we've got the requirement it's criticality yes expected development and test duration that's fair that would be for example the estimates that we're when we're estimating the cards and that will help us figure out our velocity once we have completed a certain amount of those cards all together in a sprint and the acceptance criteria for that story absolutely so what is the definition of done how do we know when that story has been developed and is a success what are the steps that we want to that we want to test it against

i really like letter c here the benefit of the feature so that key stakeholders are aware of what they'll get the benefit again is really good so some of these things could be combined but may not be in every user story and but i think the best answer here let's go with answer c there we are agile story cards should have the requirement criticality test details and clear acceptance criteria wonderful way to do it and now we're up to the last question well done guys let's see what we've got you're an agile project manager and

have begun creating user stories with your agile project team to go into the product backlog you have created the card added requirements criticality and acceptance criteria how handy we just went through that so that's a very good good order to do things in now what are we going to do next now let's see what we've got place the card on the kanban board so that the team can clearly see the future work maybe that's pretty good but we might need to do something before that like iteration planning for example have a conversation with the developers

about oh you so you've created the card oh this is good so this is the three c's maybe as well very timely that we've learned all these things in order so this is good so now if we've created it maybe we want to have a conversation i think that's probably right with developers about how the software will be used confirm the acceptance criteria and the definition of done i think that looks good prioritize the card in the upcoming sprint backlog to ensure the work gets done gosh that one looks good as well but maybe we

need to wait to prioritize it until the card is more complete so this is getting pretty tricky let's see what the last one is advise the project sponsor and risk manager of the feature details to ensure risks are captured uh i think we can safely mark that one out that's a separate process to everything that we're talking about here with creating the cards so between b and c uh let's rule out a for now because we probably need to go through b and c first before we get to a so do we prioritize the card

first or do we have a conversation with the developers about how how the software will be used i think if we're looking at the three c's of user story creation let's go with answer b great the three c's on a user story creation okay and it goes into that as well card conversation and confirmation and yeah finally we at the end of this we confirm the acceptance criteria and then you can place it in the backlog for the upcoming sprint oh and you know what else we can't place into the backlog for the upcoming sprint

is more questions because we're out of questions we actually completed all of these questions well done guys this is what an amazing achievement and if you haven't seen the other videos you know you can go back and check them out there are so many agile pmp questions ideal for your agile certified practitioner or your capm or your pmp or any other agile qualification as well and truly i've had a great time spending all of this time with you doing these agile questions to help you prepare for your exam i really truly believe that you can

pass your exam and i know you're putting in the effort and time and practice to do it and i truly believe in you keep going never give up and i'll see you in the next video bye for now