Hi everyone, welcome back to Agile PMP question practice time. A great way to pick up your skills in Agile, to test your skills in Agile, maybe to see how you're going and also to prepare for one of the exams like the PMP, the Project Management Professional, or the Agile Certified Practitioner, for example. This is a great way.
Let's jump into the questions. 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 this is from Alistair Coburn.
from the early 90s, basically, created this framework, and it was an import 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. So finding people, building people, leading people, that certainly is promising from an Agile point of view. 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, for the Agile manifesto? Profit, persistence, and power. While certainly they are things that's probably not specific to Agile in this case around people interactions.
So 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 A. 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. More at Crystal.
So this is good. Crystal is designed to scout and realizes that each project may require a slightly different tailored system. set of practices based on its size and complexity. And that's part of the big thing about Crystal 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 or miscommunicate even.
So you have to keep communication really clear and really involved. in a larger project. Crystal, metal, wood and water, based on the flow of story cards through the Kanban board.
All of these seem like they could be the right answer, but I think we're going for B at the moment. Crystal, high, low and medium, based on dollars spent on the project. And I think with crystal, there is a dollar value that is used to determine how large a project is. So it's people, it's dollars.
You know, it's the risk of the project, things like that. But crystal clear, yellow, or red 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 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. Agile and 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 standup.
What is not one of the reasons that Agile teams use daily standups? Okay, so not one of the reasons. To micro-commit to the team.
Okay, no, that's a good reason. We like that. 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. I mean, not directly.
I would 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 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. Answer 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.
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 are the project manager. Okay, oh, this is good. Probably a scenario-based question, similar to your PMP or ACP exam. 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 see how the project is actually going.
And they need to know this information because they may need to report back to their superiors as well, especially in larger organizations. All right, let's have a look. So review the Kanban board and the current work in progress. Look, that's possible. 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. 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 burndown chart, and other key performance indicators. So this will give us more of an indication.
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 burndown chart and the team velocity. Let's go with answer C. Answer C, that's great.
Agile key performance indicator. 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 overburden 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...
such as on a burndown 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 on to 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 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 Moscow 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. 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... 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 want it 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. And that is the last question for us today. You have done fantastically.
I hope you've enjoyed these agile questions. These are great. and you're improving your knowledge every single day, and the more you do these questions, the more you will improve, and I absolutely believe that you will pass the exam that you're preparing for, and I know you can do it. I hope to see you in the next video. Bye for now.