Requirement Development and Management in Agile typically includes the following –
This section presents Questions on the abovementioned topics for the required practice and builds the knowledge needed for the PMP Certification Exam.
Q1. Which of the following best defines the Product Backlog?
A. Product Backlog is a collection of User Stories.
B. Product Backlog contains the project scope.
C. Product Backlog is a baselined requirement document.
D. Product Backlog contains prioritized requirements.
The correct answer is D
The Product Backlog is a prioritized list of all the requirements required to develop or improve the Product. In Agile, we do incremental exploration of requirements, which are listed in the Product Backlog in a prioritized manner.
Typically product requirements are expressed in user stories in a Product Backlog, but it is not mandatory. You can also use other tools, so using User Story is not a must. Many assume that there must be user stories in the product backlog, but in Agile, a user story is only one of the tools for exploring requirements.
Also, apart from user stories (small size requirements), Product Backlog can contain other things, like:
Each of the above items describes requirements that the project team needs to fulfil user wants related to the Product.
Option A – “ Product Backlog is a collection of User Stories” – The Product Backlog contains user stories. Still, it can have other things like epics, issues to be resolved, knowledge acquisition, technical work, and other research related to product development.
This could be marked as the right option in the absence of option D.
Option B – “Product Backlog contains the project scope” – Product Backlog is the prioritized list of requirements; it does not describe the project scope. The scope is a solution part of the Product where we are thinking of “How are we going to meet the requirement”. Product Backlog includes “WHAT” of user’s requirements, not HOW we will meet those requirements.
Option C – “Product Backlog is a baselined requirement document” – Product Backlog is an emergent, ordered list of product requirements. Product Backlog is a Living requirement document, and it is never baselined.
Q2. While demonstrating the Product Increment in the Iteration Review Meeting, the team discovered new acceptance criteria for the done user story. So, what is the best thing to do next?
A. Mark the user story undone and move to the next iteration
B. Create a new product backlog item with incremental requirements
C. Perform a root cause analysis on missing acceptance criteria
D. Ask stakeholders about the next step
Let’s first discuss what usually happens in an Iteration Review Meeting.
The team presents the completed work to key stakeholders. When stakeholders see this usable piece of work, they often get new ideas to improve the product further, and sometimes they feel the work could have been better. It is common for these feedbacks to discover new acceptance criteria for existing user stories. Learning new acceptance criteria during the Iteration Review meeting could be an example of getting ideas to make the product more usable.
The team takes feedback and pens down items that need to be added to the Product Backlog. You can call it an Incremental Requirement or incremental Acceptance Criteria for a user story. In Agile, we do incremental exploration of requirements where adding new user stories or acceptance criteria as work progress is quite common.
Now, let’s discuss options one by one –
Option A – “Mark the user story undone and move to the next iteration” – During the Iteration Review Meeting Team shows completed work based on the Definition of Done. Meeting the Definition of Done also ensures that all agreed acceptance criteria for user stories are met. So, for the acceptance criteria which are just being discovered, there is no need to mark Done User Stories Undone. If you keep opening those user stories based on the feedback, you may never finish a user story. You never move forward, so it is not recommended to open a user story again. Rather, it is recommended to create a new item.
Another problem with this option is that – If a user story mark Undone, it never goes to the next iteration directly; first, it has to move to the Product Backlog, and based on an understanding of the priorities of the next iteration, things move to the next iteration. In case after marking undone, user stories do not go to the next iteration; the team loses the sense of accomplishment even though the team did work based on the Definition of Done.
Option B- “Create a new product backlog item with incremental requirements” – Every project has some emerging requirements because It is impossible to know all requirements in advance. In other words, discovering new acceptance criteria for a user story is common. As all newly discovered items go into the Product Backlog, we can create new Product Backlog Items with incremental exploration.
In summary, this option is a candidate for marking the right choice.
Option C- “Perform a root cause analysis on missing acceptance criteria” This option says if, during the Iteration Review team discovers any new acceptance criteria –
it is a miss by the team, and you need to understand its root cause to avoid it in the future. This option seems OK but may not necessarily be the next step. In Agile, we expect such discoveries; we do not take them as an exception.
But if you have a trend of such discoveries in the iteration review, it triggers you to do something about these gaps and focus on refining the product backlog item before you work on them. Also, later you can discuss this trend in a retrospective meeting. But, if you have to choose between B & C, B is better to do as the next step.
Option D – “Ask stakeholders about the next step” – As a project manager, it is your job to ensure proper requirement management and development. So, you and your team should be the one which tells how such things are taken care of rather than stakeholders telling what they feel is the right thing to do.
After examining all options, Option B is the best thing to do as a next step.
Q3. You are briefing about the agile approach your project is following in the Project Kick-Off Meeting; the marketing business head asked how the project will validate scope; Which of the following is true about validating scope in agile?
A. The agile way of working does not require validating scope.
B. In the agile team does the scope validation.
C. Agile teams use retrospective meetings for validating scope.
D. Agile teams use iteration review meetings for validating scope.
Let’s first see which options came out as the wrong options –
Option B says – “The agile team does scope validation” A team ensures that everything is working as per specification. So – it is a verification activity. Scope validation is an activity to check if the completed work meets the purpose. Business Owners can only do Scope Validation. In Agile, stakeholders and product owners look at the product and see – we are meeting requirements as intended.
That’s the idea about validation, so option B is wrong.
After discussing option B, option A came out as the wrong option because solution validation has to happen irrespective of the selected project approach, whether it is predictive or Agile.
Let’s look at options C and D now –
Option C says – We do scope validation in the retrospective meeting. But a retrospective meeting is more like an audit, reflection, or continuous improvement meeting. It is not a meeting where you interact with the stakeholders or business representatives. The idea of validation is –
You take your product to the business or the end-users and take their feedback or acceptance of it. Stakeholders may acknowledge some part of it and accept it for use. If they have some feedback, they provide it as input which you consider. You add those inputs to your product backlog, refine them as per prioritization, and do it as per priority.
Kindly note; you can skip an iteration review meeting for the validation. But, at the same time, iteration review meeting also serves that purpose.
So out of the available options in this particular case –
We can pick option D because other options target something else rather than validating scope in the agile context.
Q4. Your project uses an approach where the project deliverables develop incrementally throughout 2-week iterations. Which of the following can assist in evaluating the readiness of each deliverable?
A. Acceptance criteria
B. Definition of ready (DoR)
C. Iteration Review
D. Definition of Done (DoD)
In this question, you are using an Agile approach with two weeks long iterations, so you are expected to deliver a completed piece of work at the end of every two weeks.
Here the question primarily focuses on Deliverables – How do you know the deliverables are complete? Which option helps in evaluating the readiness of deliverables? Here readiness of deliverables can be interpreted as the completeness of the deliverable.
Now let’s look at the options one by one –
Option A – “Acceptance criteria” – Acceptance Criteria clarify business requirements/conditions for a product backlog item. Each product backlog item must meet its agreed acceptance criteria to mark complete. At the end of an iteration, if a product backlog item is not meeting acceptance criteria, you cannot take it as a deliverable for the iteration. In this way, this is a good option to mark right.
Option B- “Definition of Ready (DoR)” – The Definition of Ready is a checklist of criteria to decide whether a product backlog item is ready to work in the next iteration; hence it helps in iteration planning. In this way, DoR is an input to plan the iteration, not related to marking the deliverable’s completeness. Therefore, there must be better options than the Definition of Ready.
Option C – “Iteration Review” – The team presents the completed work to key stakeholders in the iteration review meeting. When stakeholders see this usable work, they check, “Are these deliverables good enough for us?” So this option is also a candidate option to mark it correct.
Option D – “Definition of Done (DoD)” – The Definition of Done helps the team have a shared understanding of product backlog item completion. Definition of Done has an agreed-upon checklist of items which each product backlog item must comply with before it is considered complete. You do not create a separate Definition of Done for each product backlog item. Instead, it gets applied to all product backlog items uniformly. But the important point is -meeting the Definition of Done ensures you also meet the acceptance criteria of each product backlog item. It means option D also covers option A.
Now let’s see which one is the correct answer – Here, we need to choose between option C or D.
Option D looks best; because – The primary intent of the Iteration Review meeting is to check if the completed work meets the purpose. If you show some work to stakeholders during iteration review, the team completes it as per the agreed understanding of completing the deliverable before iteration review.
Q5. In your project, the requirements are emerging incrementally, so you decided to use an agile approach where you don’t have the baseline scope; Which of the following helps you control scope creep and gold plating? (Select Two)
A. Definition of Ready (DoR)
B. Definition of Done (DoD)
C. Daily Stand-up Meeting
D. Continuous Stakeholder Engagement
This question answers the following question – How to prevent scope creep and gold plating in Agile when requirements are emerging incrementally?
Let’s look at what is Scope Creep and Gold Plating –
Scope Creep: – The client requests features from time to time. It results in scope creep if the team adds these additional features or functions beyond the agreed-upon scope without adjusting the project’s time, cost, or other resources.
Gold Plating: – Sometimes team adds additional features and functions beyond the agreed-upon scope to make the client happy. Usually as “freebies” for the client.
In agile, requirements emerge incrementally with no formal scope baselining. So, there is a risk of both scope creep and gold plating. Hence, the question is – How in agile do you control scope? Or Which of the following tools can help you in Control Scope?
You can say controlling Scope means you are doing –
Now, let’s look at each of the options –
Option A – “Definition of Ready (DoR):”- it helps identify how much product backlog item should be ready before you take it into the iteration. It is not specific to the scope. It is more about facilitating good iteration planning. So, it is not the correct option.
Option B – “Definition of Done (DoD)” – It helps the team with a shared understanding of product backlog item completion. Each product backlog item must comply with a checklist of items (DoD) before it is considered complete. It gives a clear idea of the number of things you should work on for a particular product backlog item. Hence, DoD addresses the gold plating because it helps in knowing items you should do to make the client happy. Understanding client happiness is not based on team judgment. This is one of the right options out of the 2.
Option C – “ Daily Stand-up Meeting” – It helps the team understand what work has been done and what work remains. During daily stand-up, the team discusses if anything impedes work and re-plans the work to achieve the iteration Goal. In this way, this meeting helps in collaboration and brings transparency. During this meeting, you may discuss scope-related items, but they do not directly contribute to control scope or gold plating. So, this is not the correct option.
Option D – “Continuous stakeholder engagement”- In agile, you encourage the team to continuously interact with the stakeholders as it regularly helps with the Inspect/Adapt. You are unlikely to start work, and after a long time, you return to show the completed work. Instead, you do the iteration review as the iteration goes on. In other words, you present your work to stakeholders frequently. Also, It is not unusual to see a stakeholder sitting with a team member discussing the current work and determining if it needs to be modified and how. This continuous engagement helps control scope (scope creep and gold plating) as it ensures work progress as per the agreement and priority.
In summary, continuous stakeholder engagement and agreement on the Definition of Done help the control scope. So, options B and D are the correct options.
Q6. Which of the following is the recommended way to define the Definition of Done (DoD)?
A. The Project Manager creates it based on historical data.
B. Product Owner makes it based on project needs.
C. The project team develops it.
D. In consultation with stakeholders, the project team develops it.
Let’s understand the purpose of the Definition of Done to know who should define it.
The Definition of Done is an agreed-upon set of items that must be met before any product backlog item is marked complete. It lists both technical and business quality requirements. It means you need the involvement of all who can contribute to exploring both technical and business aspects:
So, the involvement of stakeholders and the entire project team is needed to define the Definition of Done. Those doing the work and those validating the resulting work must share a common Definition of Done.
So, it is clear that the project team develops the Definition of Done in consultation with stakeholders. Project teams include the product owner and whoever is working on a particular project. So option D is correct.
Now let’s see why other options are incorrect –
Option A – “The Project Manager creates it based on historical data.” – The Definition of “Done” is unique for a team, so historical data might be helpful but not enough. Also, the project manager cannot just define it on his own; it needs the involvement of all (including the project manager) who knows specific quality, technical, and business aspects of the product.
Option B –” Product Owner makes it based on project needs” – The Product Owner needs to be involved, but he can’t do it alone. Because the product owner decides what the value is, and the team decides what the quality is. They all contribute to defining the Definition of Done.
Option C – “The project team develops it.” – Yes, but it has to be developed in consultation with the stakeholders. Stakeholders could be the product owner or other business stakeholders.
In summary, the Definition of Done should be developed collaboratively, and the project manager can facilitate that collaboration in developing the Definition of Done.
Q7. Which of the following best defines the User Story?
A. User Stories defines the requirement in the developers’ language.
B. User Story defines a small requirement that can be developed in iteration.
C. User Story defines the key product requirements.
D. User Story defines the product goal.
Let’s explore all options and how right or wrong they are about the user story:
Option A – “User Stories defines the requirement in developers’ language.” – A big NO because user stories are short descriptions of features from the user or customer’s point of view. A user story communicates what a user wants to do, which is the whole idea of a user story. It is not about developers’ language.
Option B – “User Story defines a small requirement that can be developed in iteration.” – Yes, it is true. A good user story is small in size you can complete in a single iteration. So, this is the right option. But let’s explore the remaining options as the question asks which option Best defines the User Story.
Option C – “User Story defines the key product requirements.” – User Story is one of the tools for exploring requirements; you can say that user stories are the best and most popular forms of product backlog items. A Product Backlog item can be a key or non-key product requirement placed in the product backlog based on their priority. Product Backlog is a prioritised list of all the requirements, so if any requirement is non-key, it will be deprioritised in the product backlog. Therefore, this option does not look like the best option.
Option D – “ User Story defines the product goal.” – User story is not about defining the product goal. Instead, it represents a small increment of requirement, which is small enough so the team can complete it as per the Definition of Done in a given iteration.
So after looking at all options, option B is the best option to mark right. Because; this option is primarily talking about –
It defines a small requirement that a team can develop in an iteration.
Q8. What is the best approach to prepare Requirement Traceability Matrix (RTM) in agile-based projects?
A. RTM is part of the Definition of Done
B. RTM is prepared in a retrospective meeting
C. RTM is usually not needed
D. Product Owner prepares RTM
The correct answer is C
Let’s first explore what Requirement Traceability Matrix is –
The Requirement Traceability Matrix looks like a grid to link product requirements from their origin (project goal) to the deliverables that satisfy them. The RTM helps to see if requirements and respective deliverables meet the business purpose.
We can put requirements in the middle of the grid & there could be forward and backward traceability.
For each requirement in the grid, we can do Backward Tracing to see –
Sometimes, a stakeholder asks, why do we have this requirement? What value is it adding? So you can go back, look at the requirement source, and give those answers. So here, RTM is a handy tool to say why we need a particular requirement.
There could be a situation when you want to know more about a requirement. If we go in a forward direction, you see –
Requirement Traceability in Agile:
You need Requirement Traceability in each project, be it Agile or predictive. But, in Agile projects, You don’t need an explicit Requirement Traceability Matrix as requirements tracking is there organically. You can see traceability from the product backlog to the sprint backlog, and the increment produced. The Product Backlog is a prioritised list of all the requirements, and this priority directly reflects the project vision and goal.
Also, you frequently show work to stakeholders using iteration review, validating the scope to see if the increment serves the purpose. This way, you may not need a separate document to track requirements. Of course, you may need to create a separate RTM document to adhere to compliances even in Agile projects, if any. But in general, you don’t need an explicit document.
So option C is the best answer – RTM is usually not needed.
Now, look at other options to clarify how well you got an idea related to the Requirement Traceability Matrix.
how can an RTM be a part of the DoD? It is the wrong option.
Option B – “RTM is prepared in a retrospective meeting” – Retrospective meeting is all about inspecting and adapting on process part of the work rather than focusing on the traceability of the requirement. So this is the wrong option.
Option D – “Product Owner prepares RTM” – It might happen that’s a possibility, but not a standard job. So, anyone can prepare it when it is needed. However, you don’t have a dedicated guy who is expected to do a Requirement Traceability Matrix preparation. The product owner is expected to prioritise the Product Backlog but not necessarily prepare the Requirement Traceability Matrix. So this is the wrong option.
Q9. Which of the following statement is NOT true about epics?
A. Epics represent a bigger requirement as compared to user stories
B. Epics get split into small user stories before we develop them
C. Epics are recorded in Product Backlog
D. Epic must get completed in one iteration
The correct answer is D; the other 3 are epic characteristics.
Option A – “Epic describes a big requirement”. It is the definition of an epic. Epic is a large requirement you cannot develop in a single iteration.
Option B – “Epics get split into small user stories before we develop them” – It is true. You never work directly on epic – you split into smaller user stories but not necessarily in one go, for example –
You make extract two stories from a large epic to develop them. Then, you may further extract three stories from one story in the next iteration and develop them.
Option C – “Epic is a part of the product backlog” Yes, it is true. Product Backlog includes both small-size (user stories) and large-size (epics) requirements. At the top of the Product Backlog, you can see small-size items, and as you go down, you start seeing the large sizes that are not yet on priority. The agile way of working with the requirement is progressive elaboration. It would be best if you did not elaborate on things in advance. You should do Just in Time because you incrementally discover and learn about the requirement. It is not a good idea to create a very refined detailed product backlog 3 or 6 months in advance. Because if you do that, whatever you have worked on this week, next week or two weeks together, and you discover some learning, you are not including those learning subsequently. So, incrementally you are expected to split these epics into small user stories and get things done.
Q10. During the iteration, an agile team discovers that it is not feasible to implement one of the user story’s acceptance criteria.
What should the team do?
A. Leave this user story and work on others.
B. Discuss with the Product Owner to find alternatives
C. Put this user story back in the product backlog
D. Raise this in the upcoming retrospective meeting.
The correct answer is B
User stories are negotiable, which means you never baseline user story requirements. You can add or remove acceptance criteria even late in development. During iteration, there could be an ongoing conversation between the team, product owner, and other stakeholders –
So user stories are not a contract but are conversation starters instead. It implies flexibility and empowers the team to question the requirements even after work starts on those user stories. The product team should be able to revise the story as soon as new information uncovers.
In summary –
You never do that, where you get some baseline user stories at the beginning of the iteration, and now you do everything and only talk about these user stories at the end of the iteration.
Once you understand that collaboration can always happen, you should do something about it. Here in this question, B is the best option where the team is opening a discussion with the Product Owner to find out what team and business people can do best for this situation.
Let’s discuss why options A, C, and D are incorrect –
Putting back into the product backlog and waiting for the retrospective meeting to happen is not a good idea. This approach undermines the whole collaboration, so the team should collaborate with the product owner and business stakeholders to discover the right thing to do in a given situation. Yes, the team can discuss this situation in a retrospective meeting if these happen frequently. But as of now, when the team discovers it, they should quickly discuss it for the earliest possible opportunity with the product owner.
Q11. The project manager is using the INVEST method to check the quality of three stories in the product backlog:
Story 1: As a user, I want to be able to select the coming Sunday using a calendar
Story 2: As a frequent traveller, I want to see my reward points balance to plan the usage.
Story 3: As a travel agent, I want to see bookings done today to project the revenue for the day.
What is the evaluation result for these stories?
A. Stories 1 and 2 are INVEST
B. Stories 2 and 3 are INVEST
C. Stories 1 and 3 are INVEST
D. All stories are INVEST
What makes a good user story? A good user story is INVEST; it is an acronym to define a checklist – To see if a user story is a GOOD user story to go in an iteration.
Independent – I stand for Independent means-
The story should be as far as possible independent. And can be evaluated end to end by looking at this user story. Sometimes you may not have an Independent User Story, but you should always aspire to have one.
Negotiable: N stands for Negotiable, indicates –
User stories are not written contact or requirements. User stories are negotiable even during their execution. You can add or remove acceptance criteria whenever you discover new information. It is never late. You should be able to talk about it all the time.
Valuable: V stands for Valuable. A user story should be valuable to your user or its consumer.
Estimable: E stands for Estimable. Team members should be able to estimate a user story to a good approximation.
Small: S stands for Small. User stories should be rightly sized –
Too large or too small cannot be used for planning. Also, each team has its definition of small. The definition of small means it should fit in a given iteration.
Testable: T stands for Testable. A well-refined user story with associated acceptance criteria and objective terms make it testable.
Let’s see user stories one by one –
Story 1: As a user, I want to be able to select the coming Sunday using a calendar
This user story is showing some gaps –
A good user story has a specific user role, like a travel agent, Jobseeker, Employer, etc. The above user story might be small but did not mention – who the user is. How is adding value to the user?
Also, this user story could be Independent or not because you might be selecting the calendar to get something done. It’s not like you select a calendar on Sunday, and something happens.
It is not an INVEST user story.
Story 2: As a frequent traveller, I want to see my reward points balance to plan the usage.
Following are the observations for this user story –
You should be able to test – Can I see reward plan points on my dashboard?
In summary, this user story looks good and has INVEST property.
Story 3: As a travel agent, I want to see bookings done today to project the revenue for the day.
In this user story – A frequent agent (User) wants to see bookings to project revenue (value). It could be like a report to project the revenue for the day. It looks like an INVEST user story that is independent, small, estimable, and testable.
User stories 2 and 3 are good. You may only partially agree to evaluate their INVEST property, but good relative to whatever options are available. You can’t select option D as user story 1 does not show INVEST property. Wherever user story 1 is there, you must remove that option. That’s why you get the option B as a good option for this question – Stories 2 and 3 are INVEST.
Q12. In the iteration review meeting, your team received the following feedback:
-The completed stories are not on business priority
-The team has not tested the stories for compliance requirements.
Overall, stakeholders are not satisfied with the work. What should the Project Manager do next?
A. Work with stakeholders and take formal, detailed feedback
B. Work with the Product Owner to ensure the requirement prioritisation
C. Revisit the Definition of Done
D. Work with the project team in the retrospective meeting to identify the next steps.
Here, the question is asking – “What should the Project Manager do next?” – Let’s see all options before deciding which is the best thing to do as the next step?
Option A – “Work with stakeholders and take formal, detailed feedback” – Yes, it could be a good idea for a project manager if he/she sees value in getting more information from the stakeholders.
Option B – “Work with the Product Owner to ensure requirement prioritisation” Here, it is clear that requirement prioritisation was missing, so the Product Owner should fix the issue related to the requirement prioritisation. So, working with the Product Owner could be a good idea here.
Option C – “Revisit Definition of Done” – It seems that compliance requirements are not included in the Definition of Done. So probably, the project manager needs to revisit the definition of compliance requirements or Definition of Done. In this way, this is also a probable right option.
Option D – “Work with a project team in the retrospective meeting to identify the next steps. “ After the iteration review meeting, the team usually does a retrospective meeting, which is a good place to talk about feedback received during the retrospective meeting. During a Retrospective meeting, the team strives to find out in collaboration with relevant people –
How to improve on something that happened in the previous iterations and develop an action plan for improvements. The goal is to bring better alignment for Business value delivery for the upcoming iterations.
During the retrospective meeting, If needed team also revisits the Definition of Done and might look at – what all compliance requirements should be a part of DoD for the completion of each product backlog item. During the retrospective meeting, instead of adding compliance requirements in the DoD, there could be an agreement to add a separate item in the Product Backlog for compliance requirements. A retrospective is an opportunity where the team reflect to see what went wrong and what has to be improved, so requirement prioritisation issues discovered during iteration review can also be discussed here. This meeting uses a facilitative approach which is always the best thing compared to one-on-one conversations. Such discussion might result in more team collaboration with the Product Owner and stakeholders. It also may result in an agreement for better involvement of the right people in the backlog refinement.
So, depending upon the type and nature of the project, these things will get fixed, and the team can find out while working as one group.
In this way, Option D is the best option as the next step. Sometimes you have more than one possible action for a given situation, but you need to identify the best.
Q13. The agile team is tasked to build a smartphone application to support drug users’ rehabilitation. Unfortunately, the team cannot find volunteer test users fitting the profile.
Which option would be most effective to ensure the best product value is delivered?
A. Do a detailed requirement analysis for user needs.
B. Release the basic version of the application and learn from its usage.
C. Develop the product based on similar competitor products.
D. Create a detailed WBS to capture the project requirements.
Here, the team needs a proper understanding of project requirements. Apart from that, the team also needs access to validate the solution. So, learning through actual usage is the only option that needs iterative and incremental development. Using iterative and incremental development, the team gradually builds up the features and functions and doesn’t wait until each of these is complete before releasing.
The question mentions that the team is Agile – so it is already following iterative and incremental development. In this way, option B is Best – Release the basic version of the application and learn from its usage.
Let’s look at the other option to see why they are not the best for this situation –
Option A – “Do a detailed requirement analysis for user needs.” This option is a wrong answer because we never do detailed requirement analysis when there is requirement uncertainty.
Option C – “Develop the product based on similar competitor products.” – It could be possible when requirements are unclear. You can take the help of competitor products to understand basic App features. But it is not a wise idea to copy App. In the case of copy, why would your customers buy your App? After a basic App version, you can evolve the product based on your customer’s feedback. So, the team can first release a Minimum Viable Product as a basic version. MVP is minimal, so there is less risk. For MVP, the team can use a hypothesis to connect the problem to be solved. During MVP development, the team does a minimum amount of work to validate this hypothesis. Once a basic version is released per the hypothesis, the team learns how users respond to it. Using this learning team decides the further direction of the development. It is a good idea to take help from the competitors’ App to develop a hypothesis for the MVP. But copying is not a beneficial idea.
Product D – “Create a detailed WBS to capture the project requirements.” – Again, detailed analysis is not advised in case of requirement uncertainties.
Q14. During iteration planning, the team finds it difficult to estimate and plan some of the product backlog items because they need to be more detailed for sprint planning. How can such situations be avoided?
A. The product owner should define the test criteria before discussing the backlog items.
B. As per the agreement in the definition of ready, the backlog items should be ready.
C. As per the agreement in the definition of done, the backlog items should be ready.
D. The product owner should create a detailed requirement before discussing the backlog items.
This question is primarily testing the understanding of the Definition of Ready:
What is the Definition of Ready – The Definition of Ready defines pre-conditions for product backlog items or user stories. These pre-conditions must be fulfilled before user stories can go into the Iteration Backlog. Meeting these pre-conditions ensures that the team does not pick unrefined user stories for the iteration; they pick only ready user stories.
A user story is ready to work in an iteration only when –
In other words, the Definition of Ready ensures user stories are refined to a level enough to start work during a sprint.
During Iteration Planning, the team picks items from the top of the Product Backlog to work on only when they see –
That these user stories fulfilling the criteria of the Definition of Ready.
Fulfilling the Definition of Ready pre-conditions requires backlog refinement activity. The team is encouraged to do refinement activity before the iteration Planning meeting. It is not possible to do proper refinement during Iteration Planning. The idea of iteration planning is to make a plan for the next iteration, not refine user stories.
Here the question is asking – how to avoid the situation where the team is finding it difficult to estimate and plan some of the product Baclokg items? The answer is – Do backlog refinement activity as per the Definition of Ready.
In the way, option B is best.
Planning and Delivering Value in Agile generally includes the following –
This section presents Questions on these topics for the required practice and grows the knowledge needed for the PMP Certification Exam.
Q15. Which of the following can the agile team use to communicate long-term product development direction?
A. Release Plan
B. Project Plan
C. Product Roadmap
D. Iteration Plan
Let’s explore these terms: Release Plan, Project Plan, Product Roadmap, and Iteration Plan.
Release Plan: The release plan predicts what the team will deliver after a few iterations. It is a Medium-Term Planning to expect what the team can deliver in three, six, or twelve months. A Release Plan is not a direction because doing planning is not equivalent to the direction.
Project Plan: A project plan predicts how the team will complete the project within a specific time frame. In the case of the Agile way of working, the team elaborate this plan progressively. However, as it is a plan, it can only give a short-term direction.
Product Roadmap: It is a long-term direction to predict what the vision team can achieve over multi-years. A roadmap shows all milestones or releases that may come in between to achieve this product vision. It is a collaborative tool to bring alignment on the priority and the high-level goals. It looks like the right option to communicate long-term product development direction.
Iteration Plan: The iteration plan aims to predict which product backlog items a team can deliver in the coming iteration. So again, it is a plan, not a direction.
So, option C – Product Roadmap is a good option in this situation.
Q16. Which of the following is NOT true about a Product Roadmap?
A. Display the strategy and direction of the product
B. Are progressively elaborated over time
C. Provide short-term and long-term visualization of the product.
D. Get baselined for tracking variances.
Let’s explore what a product roadmap is first.
A product roadmap shows a path to achieve your product vision. Product vision is the outcome that you seek. It shows why you bring the product to the market and what its success means to the customer and organisation. So product roadmap focuses on delivering value to customers and the organisation. For the product roadmap, discovering user needs is the most crucial part. You can add these user needs as themes or features. The product roadmap shows the priorities of these user needs in the strategic context (for the vision you seek) and aligns everyone around common goals and priorities. In other words, the product roadmap displays the strategy and direction of the needs. It helps to understand the user and market needs before building the product.
A product Roadmap is a living document. It is never baselined. Your user needs may change, and the market situation may change – so it must change to survive these situations. These changes give new, updated directions to the stakeholders.
You don’t usually get value by tracking variances against the product roadmap, as the product roadmap is not a project plan. However, a project plan predicts how the project will be completed within a specific time frame, and variance analysis can help determine how well the team meets that plan. So instead, a product Roadmap is a communication tool for the intent and direction to achieve product vision.
The idea here is that once the direction is laid out – the detail inside the direction will be refined, elaborated, and adjusted with time. The Product Road maps are expected to get elaborated, explained, and modified as you go along – The product Roadmap is progressively elaborated. The clarity in the path emerges as you go along as you start travelling on the path.
As a product roadmap shows a strategic context and direction – it reflects the long-term visualisation of the product. It also presents user needs that need to be implemented in the near future, reflecting the product’s short-term visualisation. The things coming in the near term need to be elaborated well. Things that are coming in the long term might be at a high level or an abstract level. So, it is true it gives us a short-term and long-term visualisation of the product direction.
So, of course – option D, “Get baselined for tracking variances.” is NOT true about a Product Roadmap. Hence option D is the correct answer.
Q17. You are planning a kickoff meeting for a project; which of the following can help establish the project context?
A. Vision
B. Release Plan
C. Project Schedule
D. Project Scope Statement
Option A is the perfect match. Let’s see how –
If you plan a kickoff meeting, you are at the start of a project. At this stage, you need to establish the context of the project. Project vision helps set the context because a vision statement includes – a short product description, intended users, key desired objectives, and key features & directions.
Once you get a context based on the project approach (Agile or predictive), you proceed with the release plan, project schedule, and project scope statement.
Q18. User testing on the last product release revealed low user interest in specific features requiring significant development effort.
A. What can the agile team do to prevent this disparity in the future? (Select Two)
B. Track Burndown chart regularly.
C. Improve Backlog Refinement Process
D. Use Work in Progress (WIP) limits for user testing.
E. Do frequent incremental releases to validate value delivery.
Let’s see each option one by one –
Option A – “Track Burndown chart regularly” – A burndown chart is an information radiator. It tracks the total work remaining, and the team manages progress by tracking the remaining work throughout the iteration and releases. But, ensuring that team is working as per the plan for delivering the deliverables may not ensure that team is delivering something which will get liked by the end-users. So yes, the burndown chart helps to see how work is trending on committed deliverables. But it can’t help in validating that end-users will like this work. So there are better options than this one.
Option B – “Improve Backlog Refinement Process” – The product backlog refinement process ensures that the upcoming iteration receives top product backlog items with appropriate and enough details to start work on them. It keeps the product backlog clean and orderly so that it may include the following –
This backlog refinement includes the involvement of the right people. If you have released a couple of times, it may give learnings from past releases. These learnings improve the product based on user needs. So, regular backlog refinement is essential to ensure learnings from past releases go into upcoming iterations. If regular backlog refinement is the issue, improving the backlog refinement process may help. In this way, it is one of the correct options.
Option C – “Use Work in Progress (WIP) limits for user testing.” – WIP defines the maximum amount of work you can place in each workflow stage. Limiting work in progress ensures the team has fewer items to finish at a particular time and helps them prioritise finishing work items. In addition, it makes the system flow faster, resulting in a fast learning cycle. In this way, it could be a possible correct option. However, let’s see the last option before making any conclusion.
Option D – “Do frequent incremental releases to validate value delivery” – If you release frequently, you will learn faster what users like and what not. Based on these learnings, you can improve the backlog refinement process.
It seems the better option than option C – “Use Work in Progress (WIP) limits for user testing. Because even if you make the testing process faster, if releases are infrequently happening, it will not help in learning about user likes and dislikes.
To release frequently, it is a good idea to learn from an MVP (Minimum Viable Product) and then do frequent MBI (Minimum Business Increment) releases. These frequent MBI releases help understand what adds value to users or customer base.
Option D looks best. So let’s go with option B and option D.
Q19. How can an agile team forecast the time to have a releasable product based on business goals?
A. By doing Iteration Planning.
B. By doing Release Planning.
C. By preparing the Product Roadmap.
D. By estimating Story points for the complete product backlog
Let’s first explore – What is a releasable product?
Every iteration delivers an increment, but the business may or may not deliver it to its users. If it goes to users, you call it a release. A release is a version of the product delivered to its users, and a releasable product comes after a few iterations.
The question asks which option can help forecast the time to have a releasable product.
Let’s see the options that we can eliminate as wrong answers –
Option A – “By doing Iteration Planning.” – The goal of iteration planning is to select product backlog items to deliver at the end of the iteration. The main focus is to explore what and how the team can build during the iteration. So, it focuses only on a given iteration; it does not help forecast the time for a releasable product based on the business goal.
Option D – “By estimating Story points for complete product backlog” – A releasable product increment may not require the whole Product Backlog, and estimation of it probably is not needed. So this is not the correct option.
So now we have two remaining options, B and option C. Let’s look at them one by one –
Option B – “By doing Release Planning” – Release planning helps explore the desired outcome for the upcoming releases. So, release planning is primarily inclined towards giving the forecast of a time for a releasable product to achieve the desired business goal. It looks like this is the correct option.
Option C – “By preparing the Product Roadmap” – The Product Roadmap is a long-term direction to explore how the team can achieve vision over multi-years. It communicates long-term product development direction. So, it focuses more on setting the path rather than predicting a timeline for an upcoming release. So this option does not help forecast the time for a releasable product based on business goals.
As you can see, option B is the correct option in forecasting the time to have a releasable product based on the business goals. The idea here is that release planning guides predict a releasable product based on a business goal rather than on detailed requirements. So, there could be an adjustment in the requirement if it is needed to achieve the business goal.
Q20. Your team is getting ad-hoc work while performing transition activities; which of the following scheduling approach may work best?
A. Iterative Scheduling
B. On-Demand Scheduling
C. Critical Path Method
D. Rolling wave planning
Correct answer is option B – “On-Demand Scheduling”
Here team performs the transition activities, which means deliverables go to the end users. When end-users start using the product, they often request changes and ask for some new features. These requests usually come on an ad hoc basis. You can not plan this dynamic flow of work in advance. In such cases, you need On-Demand Scheduling. It is the solution when teams receive work on an ad hoc basis.
Let’s see what the on-demand scheduling is.
On-demand, scheduling does not use traditional schedules like upfront baselines plans or timeboxing approaches. Instead, it works based on Kaban and lean methodologies. For example, on-demand scheduling, based on capacity and priority team “pulls” work from a queue.
The team and relevant stakeholders can see the entire workflow. The workflow shows how the work moves from start to finish through different stages represented by different columns. it radiates information on –
Due to the ad hoc nature of work, there could be a continuous flow of work from the queue, but the team believes in limiting work in progress to different workflow stages. So they define WIP (work in progress) limits for the same, Which means they have a mechanism to show how many items can be at a particular stage?
Limiting work helps to finish work faster once it is picked. Too many items in progress impede finishing them. The team focuses more on finishing work items instead start working on new items. But the team also pulls urgent work as they arrive, irrespective of WIP. The team may have a policy or rule associated with such kind of work that helps them better respond to such work items.
So, in summary, the team has the flexibility to pull in work as needed, but they do it in a disciplined manner (by establishing WIP limits ); this ad hoc work does not disturb the team’s pace.
This is how on-demand scheduling concepts work when the team receives an ad hoc basis.
Q21. On the last day of an iteration, an agile team has three out of seven items at 90% completion, team estimate it will take just one more day to finish these three items, and they can achieve 100% of the iteration goal.
How should the project manager deal with this situation?
A. Extend the iteration by one day.
B. Seek advice from stakeholders.
C. Recommend closing the iteration with current completion.
D. Start the next iteration as per schedule without closing the current.
This question is based on the concept of iteration timeboxing. Let’s see What a timebox is in a sprint or iteration? How long is a typical sprint timebox?
Every iteration has a fixed timebox, the maximum allotted time for an iteration. The team agrees on this iteration timebox – It is usually two weeks, three weeks, four weeks, or a month and is expected to stay the same from one iteration to another. The team chooses what works best for them.
As a best practice, the team must close iteration formally as soon as the timebox reaches. Let’s discuss why it is the best practice to do so:
After looking at the concept of timeboxing, option B is the best. That says – “Recommend closing the iteration with current completion.”
You might have used all the above four options in different situations. But option C is recommended as the best practice.
Let’s look at all other options to discuss what kind of issue they can create –
Option A – “Extend the iteration by one day.” – it may look attractive as you only need one day that can fix up all the issues. But then you are violating the basic fundamental principle of timeboxing. If you start doing it once, you might keep doing it more and more frequently. Many times team may end up using more days than anticipated. You will only come to know that you need more time once that anticipated one day is passed. So here you are, inviting complexity by playing with the boundaries of the timebox.
Option B – “Seek advice from stakeholders” – Continuing or stopping iteration is a process-related decision, and you are the process owner. And it is not advisable to involve stakeholders unnecessarily.
Option D – “Start the next iteration as per the schedule without closing the current” – In the real world, many professionals do it. Still, having two iterations running without closing the previous iteration is not a good idea. Reason is –
So, all those things start getting confused when you start taking this workaround. It makes the whole process complicated.
Q22. Which of the following are needed to do release planning? (Select Three)
A. Release Goal
B. Resource Calendar
C. Estimated Velocity
D. Estimated Product Backlog
E. Definition of Ready (DoR)
Okay, let’s discuss all options one by one:
Option A – “Release Goal” – Understanding the release goal is the starting point for release planning. You should articulate the goal for the release and how this goal is aligned with the product vision and strategy. Following are a few examples of a Release Goal:
So for the release plan, you need an understanding of what you are trying to achieve. What is the purpose of doing this release, and what goal is it has?
Option B – “Resource Calendar” – The resource calendar shows the availability of resources by reflecting working days, vacations, leaves, and non-working days for individual resources. You don’t need a resource calendar to plan a release because release planning does not look at individual-level accountability. Instead, it sees what a team can release as a whole. Release planning is about something other than who is taking leave; what is their engagement level for this whole duration, or what all team members are allocated for a particular time?
Option C – “Estimated Velocity” – Velocity is the average amount of work a team can complete in one iteration. Estimated velocity implicitly considers information that the resource calendar provides –
It is an essential input to developing a release plan as it gives information on how many iterations the team needs to accomplish the release goal.
Option D – “Estimated product backlogs” – It is an important input in release planning. The items linked with the release goal need to be estimated because, in the absence of that, how will you identify a possible timeline and release date?
Option E – “Definition of Ready” – The Definition of Ready helps identify how much product backlog item should be ready before you take it into the iteration. It does not help to predict anything related to the release plan.
So, the correct options are the Release goal (Option A), Estimated velocity (Option C), and Estimated product backlog (Option D).
Q23. Which of the following can help determine the rate at which deliverables are produced, validated, and accepted?
A. Throughput
B. Burndown Chart
C. Burnup Chart
D. Cost Performance Index (CPI)
Let’s see first which option we can eliminate as the wrong option easily –
Option D – “Cost Performance Index (CPI)” – This option is easy to rule out because the cost performance index is the ratio between the earned value and the actual cost. It gives information on how well you adhere to the budget and use the money.
This option does not help determine the rate you are producing, validating, and testing deliverables.
Let’s look at the remaining options –
Throughput, Burndown chart, and burnup chart are directly or indirectly related to the progress of deliverables. So let’s see which is best in determining the rate at which deliverables are produced, validated, and accepted.
Option A – “Throughput” – Throughput is a measure of how many deliverables have been produced and validated in a given time box. So with that definition, throughput seems to be the candidate option for the correct choice.
Option B – “Burndown Chart” – The Burndown chart shows how much work remains in the iteration. It also shows how the remaining work is getting reduced. The slope of the burndown chart does help us identify a possible rate at which deliverables are produced, validated, and accepted.
Option C – “Burnup Chart” – The burnup chart shows the total completed work. The burnup chart’s slope also helps you identify a possible rate at which deliverables are produced, validated, and accepted.
After looking at the definitions of throughput, burndown chart, and burnup chart – throughput is the more appropriate answer because the objective of throughput is primarily to tell about the delivery rate. On the other hand, the primary purpose of the burndown and burnup chart is to show what is left and what is completed, respectively. Therefore, these are trend-oriented metrics rather than showing progression at a particular rate.
For example. If you’re a pizza store and you tell that on average, you dispatch 1000 pizzas, and that’s your throughput for the day. It shows the number of pizzas that produce, validate, and accept on a particular day, and that helps you plan for your upcoming capacity and days.
In the PMP exam, you need to choose the best option, and option A is the winning option In this particular situation because that’s primarily about the delivery rate.
Q24. An agile team is making good progress on key requirements, but defects in deliverables are accumulating in the backlog. Most of the defects are minor and take half a day to fix. Which approach would be most effective in stopping the accumulation of minor defects?
A. Reserve some capacity in the iteration for defect fixing.
B. Add Special Product Backlog Item to fix these defects.
C. Integrate the fixing of defects in the Definition of Done.
D. Start estimating the defects in Story Points.
All these four options have some value and can probably help us reduce defects, but here we are looking for the option that can help minimise defects’ accumulation. Let’s explore which option is most effective in stopping the accumulation of defects –
Option A – “Reserve Some capacity in the iteration for defect fixing” – Reserving some capacity might be a good idea for already accumulated defects. If the team has discovered some defects, they may fix them rather than just work on the new requirements. Fixing defects takes some percentage of iteration capacity. This option may reduce the number of defects, but accumulation may still happen. Since the team is fixing, overall absolute accumulation may start reducing, hence is a good option.
Option B – “Add Special product backlog items to fix these defects” – You may add one or multiple items to the product backlog to focus on fixing defects. It shows that you have an accumulation of defects and can add them to the backlog, which may make them visible. At some point, you can fix it, but adding things to the backlog may continue the accumulation of it. It may make things visible and start giving a good focus on the conversation, but it does not necessarily take care of the incremental accumulation of defects.
Option C – “Integrate the fixing of defects in Definition of Done” – What does it mean? Knowing when a product backlog item can be marked Done is a shared understanding between team members and stakeholders. The team defines a Definition of Done for this shared understanding: A checklist of items that each product backlog item must comply with before it is considered complete. So if the team includes something in the Definition of Done, every product backlog item must comply with it mandatory to mark it as complete.
If the team includes fixing the defects in the Definition of Done, they can only mark a specific item as Done once defects related to that item are also completed. So, you won’t be able to say a feature is complete if it has some minor defects. Hence, you better fix them then and there; that’s a preferred approach. Most of you must have faced this experience that fixing an issue when it is fresh is easy. But if these issues start accumulating and one issue may start getting related to the other issue, then resolving them may become more and more challenging—usually, the time to take fixing increases if you keep delaying that fixing.
So, fixing defects before marking a particular item complete creates the proper sense of completeness for items. This option looks helpful in stopping the accumulation of defects. Let’s see what the last option is.
Option D – “Start estimating the defects in story points” – Estimation of defects and showing and quantifying those defects as problems is a good idea. Of course, that makes people more aware, but awareness may lead to some action items. Still, more than just awareness is needed to stop the new defects’ accumulation directly.
So option C is the best option. You need to improve the Definition of Done, which should include fixing the minor defects in this question.
Q25. In a Hybrid Project, the agile track expects a change to be implemented by the predictive track, whereas the predictive track is waiting for Change Control Board (CCB) approval. The delay in change approval frustrates the agile track; how can a project manager reduce such a situation?
A. Assign a single person to resolve such issues
B. Establish a clear mechanism to track issues
C. Improving communication between agile and predictive track
D. Recommend Adaptive ways of working for a complete project
In such a hybrid situation, integration is usually the most challenging thing the project manager has to deal with. So let’s look at the options to choose the best to reduce such challenges:
Option A – “Assign a single person to resolve such issues” – In this case, you have a manager who takes care of the issues, so you have an Issue Manager. It might work, but that single person may also become a bottleneck. You need to see if putting this person is helpful or can create further problems because if the single person is not handling it well, you may have a bigger mess. In general, you need to know the details about the situation before you can say whether or not a single person will be good. That’s something you need to see. You can’t just see based on the question you have in front of you. This option does not look like a good option.
Option B – “Establish a clear mechanism to track the issues” – For issue tracking, you may have a board, and you put those issues on the board, and everybody can see them. So, if any issues are delayed, you have a clear awareness of them and can do something about them. It could be a good idea to track issues, communicate them, discuss them in various meetings and milestone reviews, and make them visible. This tracking will improve the resolution faster.
Option C – “Improve communication between agile and productivity track” – Yes, there should be better communication so that the changes can be –
Hence, improving communication between an agile and predictive track is also a good option.
Option D – “Recommend adaptive ways of working for a complete project” – If a project uses a hybrid approach (mix of predictive and adaptive ways), there must be a reason behind it. So, recommending adaptive ways of working is not a wise idea to avoid the challenge of communication between two tracks. It would help if you explored what you can do to address this challenge instead. Directly jumping to change the life cycle is the wrong thing to do. Hence there are better options to choose.
Now we need to choose from options B & C; for that, we need to check whether we should have a good tracking system (Option B) or focus on improving the communication between Agile and Predictive Track (Option C). Tracking can help you to resolve this situation, and improved communication will be more helpful in reducing such situations.
Reducing such situations where we have a delay, we have late information, and which create wait time can be improved if we have early identification of the issues and early processing of these issues. Option C looks best because it discusses reducing such situations.
Q26. Which of the following assists an agile team in planning their day at work?
A. Iteration Planning
B. Release Planning
C. Daily Stand-up Meeting
D. Team Charter
Directly or indirectly, all four are influential in planning the day at work, which makes the question a little tricky. It would help if you found out what is the most and which one is the most appropriate for a given day.
Let’s first explore all of these options –
Now let’s see how these options influence a day at work –
The release plan shows all goals the team needs to achieve iteration by iteration. The team generally execute a specific iteration and does Daily Planning for each day to see how the team is moving toward the iteration goal. Team charter help governs how the team works and interacts, which helps them do work appropriately.
So, the release plan influences the iteration plan, and the iteration plan influences the day’s work. And a clear indication is that team discusses day work in a daily stand-up meeting.
So, option C – “Daily Stand-up Meeting”, seems the best option to assist an agile team in planning their day at work.
Whereas other option also may influence or helps the team in framing or creating what the team is doing on that particular day, the Daily stand-up influences the team’s day at work.
Q27. Who creates the Iteration plan?
A. Project Manager
B. Team
C. Scrum Master
D. Product Owner
So, let’s explore different roles in the context of creating the iteration plan –
Many of you come from a traditional project management background. Whenever the word Plan comes in, you may think planning is the accountability and responsibility of a project manager. So, you pick up the Project Manager whenever the word Plan comes. Not valid in the case of the Agile way of working.
In an Agile way of working, the project managers are more on facilitating space, and the team does detailed level planning, not the project manager.
That’s the idea, so the project manager (Option A ) goes out.
Many of you may say developing the iteration plan is the Scrum Master job. I have seen in my company Scrum Master creates the iteration plan. That might be happening in your company, but that’s not the right thing to do by the Scrum Master. The idea here is Scrum Master creates a self-organising team. A self-organising team should be able to plan their work, execute their work, monitor their work, and adapt their work to achieve the goal. Still, the leadership, project manager, product owner, and whoever is in the leadership space should help them set the goal, direction, and priorities. So, leaders help them identify which product backlog items are the priority items to develop the iteration goal. But after that, planning and executing that is a team’s job.
In this way, option C (Scrum Master) goes out.
So, in this question, we can directly go with the answer B ‘Team’,
Let’s discuss – why not the product owner is the correct answer –
A product owner works closely with the business to determine what is needed next. A Product Owner has great insight into the business and finalises what the team should do next. Still, the planning of that execution is primarily on the team so whenever you see a question related to detailed planning, figure out how I should do my job. In general, you should focus on the team or the individual executing it because the overall essence of modern-day management is self-organising and more and more autonomy for execution to the person doing the job or through the team who is doing the job.
In conclusion, Option B is the right answer – The Team creates the iteration plan.
Q28. Which of the following are the outputs of the Iteration Planning meeting? (Select Two)
A. Iteration Goal
B. Iteration Plan
C. Definition of Done
D. Estimated Product Backlog
It is a simple question, and options A (Iteration Goal) & B (Iteration Plan) are easy choices. Therefore, you should be able to pick A & B.
Now, if you are finding this question a little tricky, you need to study how these various agile meetings operate, their goal and what are their objectives or the output they generate at the end of it.
For the PMP exam, Iteration and Sprint are synonyms. So, for example, they may use a word that which of the following specific output of Sprint planning meeting? And they may use the word Sprint Goal instead of Iteration Goal. Similarly, the Iteration plan, Sprint Plan, and Sprint backlog are the same. So be aware of these terminologies, and then you will understand how these things work.
Now, if you are still confused –
Because the Definition of Done is an agreement for completing each Product Backlog Item. It is the checklist and creates a shared understanding of all items the team needs to do to mark each product backlog item as complete. So, before the team get into an Iteration planning meeting, they should have a Definition of Done. The Definition of Done is technically input to the Iteration planning meeting rather than an output.
Also, the Product Backlog is getting estimated in a Backlog Refinement Meeting; It’s not a one-time job; it’s a regular activity as the product backlog items are emerging regularly. Therefore, the team should not do Product Backlog estimation in the iteration planning meeting.
Q29. Which of the following techniques can an agile team use to ensure project activities comply with organisational and project policies, processes, and procedures?
A. Quality Audit
B. Frequent Delivery
C. Backlog Refinement
D. Iteration Review
This question is asking how you ensure organizational-level process compliance.
First, let’s explore options most relevant to Agile Approaches – Frequent Delivery, Backlog Refinement, and Iteration Review.
Frequent Delivery: In Agile, the team plans to deliver frequently every couple of weeks or so. It helps to release product features early to stakeholders and customers, ensuring the team receives feedback regularly to evolve product features continuously.
Frequent Deliveries do not help to comply with organisational and project policies, processes, and procedures.
There could be a violation of organisation policies when the team is still delivering frequently.
Backlog Refinement: Product backlog refinement is an activity to clean and order the Product Backlog. It is an activity where the team can add or remove items, change items’ priority, split big to small sizes, etc., to the product backlog.
Sometimes the team may add an item to the Product Backlog because of organisational policies and procedures. But directly, Backlog Refinement is not contributing to ensuring project activities comply with organisational and project policies, processes, and procedures.
Iteration Review: After every iteration timebox, the team shows the completed work to the stakeholders in the iteration review meeting. This meeting helps to know if the team is working in the right direction, which features need further improvement, and which features the team should have developed as per expectations and need improvement. Iteration Review does not help to comply with organisational and project policies, processes, and procedures.
So, which option is left? – Option A – “Quality Audit”
Quality Audit seems traditional; professionals who belong to Agile hardly hear this kind of term or word.
But when preparing for the PMP exam, you can assume that there could be a mix-up of agile approaches and project management terminologies. So you need to get into the essence of these terminologies even in the Agile world.
Quality audit is the process of systematic examination of organisational and project policies, processes, and procedures. In Agile, you may do a Quality Audit –
So, you may not have a special meeting called Quality Audit. It is a kind of work. It’s not a necessity. Meeting
But in general, a Quality Audit is to ensure that the team adheres to the organisation’s processes and policies.
So the correct answer is – Quality Audit, which ensures project activities comply with organisational and project policies, processes, and procedures.
Q30. A hybrid automobile project runs agile software and predictive electronics tracks. Incidentally, delays accumulate halfway into the project due to misaligned deliverable releases between the two tracks.
What should the project manager do to improve this situation?
A. Develop an Integrated Project Schedule for both tracks.
B. Improve communication by revisiting the communication management plan.
C. Conduct a Retrospective with an agile track to identify improvements.
D. Assign Team Leaders for both tracks to ensure alignment.
In this question, you have one agile track, and another is predictive. And each track has its release milestones or processes, but there is no alignment between them, creating issues and overall delays. So how should you handle it as a project manager?
Let’s look at the options. Which one would you like to take?
Option A – “Develop an Integrated Project Schedule for both tracks.” – It might be tricky. Agile projects have little predictability in getting a project schedule like predictive project schedules. So this option is not the right to solve the problem.
Option B – “Improve communication by revisiting the communication management plan.” – The overall idea is to address collaboration and communication issues. For example, if you have a different release date and cannot track what is happening, – A change request in a predictive track might delay something in the Agile track. And the agile guys may be dealing with a challenge which may affect the predictive track. You can improve such problems by introducing joint planning meetings, sharing information, using information radiators, dashboards, etc. You should revisit the whole communication process to facilitate these tools. In this way, this option looks promising. But it is about more than creating a document as a communication management plan; it is about developing the right communication strategy.
Option C – “Conduct a Retrospective with an agile track to identify improvements” – It may be a good idea, but the problem is wider than the agile team. The problem is also in the predictive team. So focusing and working with only an agile team is not enough to solve the problem. So this option goes out.
Option D – “ Assign Team Leaders for both tracks to ensure alignment” – It may be needed, which you can cover in the communication management plan. For example, you may need to have a communication channel in which you may have information exchanged with a particular person. But in the question, there must be a clear indication that centralised management can solve the problem. You need a clear idea in the question that you need two managers to handle and facilitate these particular alignments. In the absence of this idea, this option does not look promising.
So option B looks more agile, more systematic, and more integrated, saying improve communication by revisiting the communication management plan.
There could be many other options, but in the PMP exam, you need to pick the best option out of our available options.
Agile metrics provide insight into team progress and performance for the iteration and releases toward meeting its goals and objectives.
This section includes questions for the following –
These Agile metrics help the team monitor performance across all planning and value delivery stages.
Q31. Based on the velocity chart of the last 6 iterations, how many iterations do you estimate for finishing 100 story points of work?
A. It can’t be calculated
B. 3 to 4 iterations
C. 4 to 5 iterations
D. 5 to 6 iterations
In this question, you need some calculations and some understanding of Agile.
Let’s first explore – “What is velocity?” And how it helps calculate the number of iterations in the release.
The velocity represents the quantum of work a team can mark done in a given iteration. So simply 100 Divided by velocity tells me the number of iterations. So can you read that information from this particular bar chart?
The length of the bar represents the velocity observed in a given iteration. You can see that there are different velocities for different iterations. Here, you have 100 points of work done, and you can divide it by the velocity and find out how many iterations this particular work will need. But here, you don’t have a given velocity. Instead, you have a chart, so what do you need to calculate the number of iterations required?
In general, you use velocity data from recent iterations. If you see the trend in the bar chart and take the average, it may come to around 22 – 23. But is it relevant to refer to velocity from the recent three iterations and take the average out of that recent number to calculate, predict or estimate rather than, say, to estimate the future velocities. Here, you should focus more on the last three iterations than the previous 3. Yeah, so you concentrate on 20,25 and 30. Now, if you take an average, it comes to around 25. The pessimistic estimate could be 20 because out of the last three, 20 was the slowest and 30 was the fastest. So if you go the fast speed, you still need three plus iterations. You need more than 3. Yeah, and if you go slow, you need five iterations because 100 / 20. So it takes around 4 to 5 iterations, and that’s why option C wins here because the pessimistic could be 20. Your optimism could be 30, and Most Likely is around 25; looking at that, 4 to 5 iterations are good enough.
So pessimistic will go towards 5, optimistic could be three and a half or something, but we better focus on the manageable number, 4.
Sometimes, you may face just one number, but you still need to use your judgment. Take the recent observation and focus more on the recent data than the past data. And this is how you can calculate the number of iterations needed for the given work.
Q32. The table below represents the status of user stories at the end of the iteration. What is the velocity of this iteration?
A. 19
B. 23
C. 11
D. 15
Let’s explore the velocity of this iteration; here, the available options are just numbers 19, 23, 11 and 15, and the whole idea is about the calculation. –
The team completed stories (B, C, D), and you should count them in the velocity. The only question is about A and E. Should you add some points from there? If yes, how many?
So you see here that the team completed story A, but it needs to meet the Definition of Done, and that’s the only information provided. The story E clearly shows that it’s partially done 50%, and it’s not meeting the Definition of Done. Now you may be inclined towards considering story A and E as a part of velocity or some part of Story Point as a part of your iteration velocity because both are big; they are 8-pointers. If you consider something, your iteration velocity goes up.
So Please remember the role when calculating the velocity – it is only about Done and Not Done.
You can consider the Done part only. You don’t have anything to do with a percentage completion, or anything is left. Also, please be aware there is no almost meeting Definition of Done. It’s meeting or not meeting. So, in this case, the calculations are simple, you need to total B, C & D, and the answer will be 11 only. There is nothing else. So, you must count the DONE part of iteration work: stories B C and D.
The team may suggest splitting user stories and telling the Done part of spitted user stories to count in the velocity, which is fine. But in the question, there is no indication of splitting user stories.
So the correct answer is Option C – 11
Q33. The release was planned in four iterations. What can be inferred from the burndown chart below? After the third iteration. (Select Two)
A. The Release is behind schedule
B. The release is ahead of schedule.
C. 100 story point of work is pending
D. 100 Story point of work is done
Here you have a burndown chart, and you need to pick up two statements out of four which you can reasonably interpret from this particular graph.
What information is available here? For example, what is the X axis? What is the Y axis, and what is represented by the lines?
So, what is a burndown chart? It is an information radiator to track the remaining work and helps manage progress for the remaining work throughout the iteration and releases. In addition, the Burndown chart allows seeing how work is trending on completing deliverables.
With this information in your hand, how do you see various options? So let’s look at the option now. You have a fair understanding of the graph and its lines and parameters.
The release is behind schedule. Why? Because you have more remaining work left than expected, whenever, in a burndown chart, your actual is above the expected line, it means you have more than anticipated. And what is this more number? It’s the remaining work, so when you have more remaining work than anticipated, then you are behind schedule. So option A is correct.
In this way, you don’t need to look at option B – The release is ahead of schedule because you need to catch up.
Let’s look at C (100 story point of work is pending) and D (100 Story point of work is done) now.
You started from 200 and are now at 100 stories point work. What does it mean? Have you finished a hundred, or do you ever pending 100? Or does it mean both? Yeah, both, so the answer here is that you have a pending of 100. That is perfectly clearly coming out.
The remaining work equals the total work minus the work Done.
So the answer will be A and C because the burndown chart always shows what is remaining, and you can see the remaining is more than the team anticipated.
Q34. The release was planned in 4 iterations. What can be inferred from the Burndown chart below after the 3rd iteration? (select Two)
A. Work was added in the 3rd iteration.
B. The release is ahead of schedule.
C. The team has a consistent velocity.
D. The team was ahead of schedule in the second iteration.
The Burndown chart shows how much work remains to complete at a particular point. An axis shows the iteration number, and a Y-axis represents the work remaining. The blue line represents expected or planned work, whereas the orange colours primarily focusing on the actual work burned.
Here, options seem tricky and require more interpretation of these particular burn-down charts. So let’s go one by one.
The team added work in the 3rd iteration. So how would you see it? You see that in the second iteration,, you had less than 100 points of work left. And at the end of a 3rd iteration, you have more work left because the line went up.
So how is it possible that after finishing 2 iterations, when you finish the 3rd iteration, you have more work left than where you started? So it can only happen when your work gets expanded during the iteration. Work could get expanded based on various possibilities – One possibility is that new scope got added. Another case is that you end up resizing your remaining work. The 3rd possibility could be that more defects got recognised. So, something has happened which has expanded the work. More work was added, or a re-evaluation of work was done.
Here definitely, you are behind schedule. The team was ahead of schedule in the second iteration because, at the end of the second iteration, the remaining work was less than the anticipated work. You can see the actual line was below the expected line in the second iteration.
So if you have to choose with this particular graph for this specific question, options A (Work was added in the 3rd iteration) and D (The team was ahead of schedule in the second iteration) are correct.
You can’t say that release is ahead of schedule and the team has a consistent velocity.
Q35. The release was planned in four iterations. What can be inferred from the burnup chart below after the third iteration? (select Three).
A. The release is behind schedule.
B. 100 story points of work is done.
C. The team size is reduced in the third iteration.
D. The velocity of the second iteration was more than the. First
You need to find one statement you cannot infer from this chart. So there are three true statements and one false statement.
Let’s go to a diagnosis of this particular chart. So what are these X-axis Y axis, and two graph lines? A burnup chart is a graph that shows project progress or the amount of work done over time. Two main lines, one (here orange line) for the anticipated total work and the other showing actual work completed (blue line). So, the blue line shows actual progress, whereas the orange line, in this particular case, shows you the target or goal. Here, the graph shows actual work burned and target work in Story Points.
Now. Now let’s see what we have in the options –
Option A – “The release is behind schedule” – The release is behind schedule – You need to calculate the remaining work by the difference between these two lines. At the end of 3rd iteration, the remaining work is 100, whereas it should be around 50. You have more work left than anticipated because you can complete 50 story point work per iteration. This information is not reflected in the graph, but you can fairly say. There is no clear statement, but an obvious indicator is coming.
Option B- “100 story points of work is done” – You are at the end of iteration 3. The graph shows 100 story points work is done.
Option C – “The team size is reduced in the third iteration” – There is a decline in the velocity in the 3rd iteration; there could be some challenges. There could be some poor technical results or something else. It’s tough to say that team size is reduced in the 3rd iteration. So this is the correct option.
But still, let’s look at option D -“The velocity of the second iteration was more than the first iteration” – This is coming from the clear slope of the line. The slope shows more burnt points in the second iteration. During the first iteration, the team burnt around 30 or 40 story points, but in the second, they burnt around 50 or 60 story points.
Without much of an assumption, you can interpret –
– that team is behind because 50% of the work remains; they are left with 25% of the time.
– In contrast, the information about team size (Option C) is not a clear indicator from this particular graph.
So if you have to choose the answer, you should go with A, B & D, which means option C cannot be inferred from this particular burnup chart.
Q36. Below is the team’s Kanban board on the 9th day of 10 days of iteration. What can be inferred? (select two)
A. work is on track
B. No story is done
C. Story B and C will get tested tomorrow.
D. The probability of Finishing Story F is higher than others.
Here the team uses the Kanban board to track and manage the flow of work and visualise the items in progress.
Let’s look at the options –
Option A – “work is on track” – This information is not coming directly from this graph. You just left with one day, and everything needs to be completed out of the six items you picked up. So it’s doubtful to be on track, but the graph does not say explicitly. Some other information can say that everything remaining is small and you will get it done, but you need help seeing this extra information from the board.
Option B – “No story is done” – Yes, definitely nothing is done because there is nothing in the done column.
Option C – “Story B and C will get tested tomorrow.” – How do you know from this board? It might be true, but difficult to say from this board.
Option D – “ The probability of Finishing Story F is higher than others.” – It’s clearly coming because story F is already reached the testing state, and the board is not showing any blocking or anything happening at a story F.
So options B & D are the best answers coming from this Kanban board.
Q37. Below is the team’s Kanban board on the 7th day of 10 days of iterations. What advice would you give to the team?
A. start developing story A and D.
B. Find ways to finish story F.
C. Find ways to move story B,C & E to the test.
D. No advice as work is going good
You are already halfway through and should have some items in the Done stage. So in Agile, you should not wait for the last date to mark everything finished. I always talk about incremental development. So you can see that things are not happening that way, and you probably, as a project manager, team leader, or scrum master, need to give some advice.
So option D is incorrect.
Kanban focuses on the practice of stop starting, and start finishing. – Once the team has started any work, they pay special attention to not starting more and more work. First, they concentrate on finishing what is already in progress. So in the Kanban way of working, the team walk the board from right to left. So from a Done column to a backlog column rather than a backlog column to a Done column. It is because the team want more and more completion instead of starting.
So option B is correct, which is more focusing the work to mark Done. The more you mark Done, the more you make things usable, It is incremental finishing of work rather than keeping a lot of things in flow, and nothing is Done. An efficient flow keeps the work in progress to a minimum. By finishing story F, you have at least one item complete.
Your second focus is that you should move some items placed later in the Kanban board towards finishing (option C), and then finally, you start some new backlog items (option A).
Q38. Below is the team’s Kanban board at the end of an iteration. What is the team’s velocity?
A. 14
B. 13
C. 18
D. 15
What is the velocity? It is the amount of work Done in an iteration. There are six stories on the board with their size mentioned.
Here, only four stores are Done, and B and D still need to reach Done Stage. Do you need to take some credit for these two stories? The answer is No. So what is velocity?
It comes after summing the total size of items marked Done. So you need to just pick up the size of these four stories (F, E, C, A) – 5 + 1 + 3 + 2 + 5, which is 13, and that’s the answer – Option B
You may want to take at least one point from the test and at least 50% from development. Please don’t get into that trap. It’s simple; ideally, you should have small stories, so you don’t have such issues. On the other hand, if such issues are happening in your ongoing iterations. In that case, you should figure out how to avoid it in the retrospective rather than start finding some calculating means to show that you are doing good and not fixing the underlining problem.
Q39. The team uses on-demand scheduling. So below is the team’s Kanban board at the end of the week. What is the team’s throughput for the week?
A. 3
B. 5
C. 9
D. 11
So here the question is about on-demand scheduling which is based on capacity and priority and the team “pulls” work from a queue. So what is the throughput here on the board? It is the measurement of the team’s work that has moved from one stage to another stage over a certain time – day, week, or month.
You can see from this board what the team has done this week. So if you can find that from this board, done means completed in this particular week, that will be throughput, and the work will keep moving. So throughput is 5 (Option B) by counting the number of items completed at the Done stage.
In throughput, you count the number of items completed; you don’t see the size of the work. If you count the amount of work done, it is velocity, not throughput.
In Agile, incremental delivery and feedback typically include the following –
This section presents Questions on these topics to practice and creates the knowledge needed for the PMP Certification Exam.
Q40. A hybrid healthcare equipment project runs both an agile software track and a predictive electronic track. Halfway into the project, a new risk impacting both tracks was identified in the electronic track. What should the project manager do next?
A. Attend the daily stand-up of the agile team and inform them about the risk.
B. Recommend product owner to discuss and plan risk response in the Backlog Refinement.
C. Call a special meeting with the complete Agile team to discuss this risk.
D. Add this risk to the agenda of the upcoming retrospective meeting
Let’s explore each option one by one –
Option A – “Attend the daily stand-up of the agile team and inform them about the risk” – Attending the daily standup of the Agile team and informing them about the risk it’s a good idea if the risk impacts the current iteration. But if the impact is not on the current iteration, then no action comes out of that conversation. You probably need to handle it elsewhere instead of in a Daily standup meeting.
Option B – “Recommend product owner discuss the and plan risk response in the Backlog Refinement.” – Recommending the Product Owner discuss and plan risk response in the Backlog Refinement could be a good option to take care of the risk and its response in the Agile Track. However, before concluding, let’s see other options.
Option C – “Call a special meeting with the complete Agile team to discuss this risk“ – It is a good option only if you have an emergency. When the team is working on the current iteration, you should let the team work on it. There is no such indication of a crisis in the question, so you should not disturb the agile team in the current iteration.
Option D – “Add this risk to the agenda of the upcoming retrospective meeting” – Retrospective meetings help reflect on what processes the team can improve instead of executing some part of any process. You need a risk response plan for an identified risk in this question. So, there are better options than this because the retrospective meeting can primarily focus on how you missed identifying that risk. If you want to do that, the retrospective is an excellent place to talk – Like how you can improve the risk identification process. But you have an identified risk which needs to be analysed, and you need to see how to respond differently. Talking about it and waiting for a retrospective meeting to happen doesn’t seem to be a suitable choice
After looking at all the options, you can see that option B is the right choice – Recommend product owner discuss the and plan risk response in the Backlog Refinement.
Backlog refinement is a continuous activity, and the Product Owner can facilitate discovering an appropriate risk response plan for the identified risk.
Q41. Your project will help the organisation launch a new product for a new market. Since it’s a new product, many requirements are based on assumptions.
What will be the best way to validate assumptions?
A. Conduct a user interview.
B. Do frequent demos to the stakeholder
C. Deliver a minimum viable product.
D. Give a presentation of assumptions to the stakeholders.
All four options are good. You need to find out the best way to validate assumptions in the Agile approaches when introducing a new product in a new market space.
Option A: “Conduct a user interview” – It’s a good idea. Whenever you want to do something, you discuss it with the stakeholders and understand their needs and expectations. If you talk to users, they can also give you a better perspective of their needs. So it’s good to find the requirements and validate some of your assumptions.
Option B: “Do frequent demos to the stakeholder” – It is also a good option because it helps you showcase completed work and get feedback for –
The above feedback helps in validating many assumptions.
Option C – “Deliver a minimum viable product.” – Minimum Viable Product (MVP) is the smallest collection of features you can include in a product for customers to consider it functional. MVP may not benefit the business, but it is an excellent opportunity to learn customer and user behaviour and collect more insightful inputs. So, if you release something functional quickly, you may know many things users may not explicitly tell you. Hence, you can validate assumptions (or hypotheses) using MVP in the shortest possible time. In other words, Minimum Viable Products help to test assumptions and hypotheses related to the product value propositions.
Option D – “Give a presentation of assumptions to the stakeholders.” – It is also a good idea, but it is not as good as delivering MVP. You release MVP to either real users or representatives of the customer segment, which can be a fundamental tool to test your assumptions or hypothesis. Giving a presentation is a discussion, and you can validate assumptions in only abstract form. But, the actual use of the MVP provides a real sense of how your hypothesis works for the users.
After exploring all options, you can see that option ‘D’ is not suitable; now, we need to choose between options A, B, and C.
Option A talks about user interviews; in this case, users can share information only based on your questions. It is not an opportunity to get feedback from the real use of the product. So, if you compare option C with A, option C is a clear winner. So now lets’ compares option B and Option C to see which one is best –
Option B talks about giving frequent demos, But this option is just demonstrating to the stakeholders. It needs to be clarified if, in these stakeholders, you have end users. Stakeholders may be internal and external – here, if you have the new product market and customer segment representative, it is a decent place to collect feedback. You can get real feedback if the stakeholders have end users.
But option C involves end users in the question, so the best answer is option C- “Deliver a minimum viable product.”
Q42. Your team has planned an iteration and identified some risks in achieving iteration goals.
What is the best way to track these risks?
A: Make risks visible and review them in daily stand-ups.
B: Add the risk to the risk register and assign a risk owner.
C: No tracking of iteration level risks is needed.
D: Conduct a weekly meeting to review risks.
Let’s first see more about the situation mentioned in the question –
The team has done Iteration Planning Meeting. The output of the Iteration Planning meeting is –
Iteration Backlog is the portion of Product Backlog that team has planned for the current iteration. During the iteration planning meeting, the team observed some technical, people, or management-related risks for the iteration work, which may impact the iteration goal. Now, what should you do about those risks?
First, explore option one by one –
Option A – “Make risks visible and review them in daily stand-ups.” – When the team identifies risks, they should first make them visible to facilitate time-to-time review and discussion. As risks can impact the current iteration, the team must keep their eyes open to see if these risks can become a reality and what risk response can help. Hence, Daily stand is the best place to review risks – is there any risk which can derail the iteration goal? And if it is true, the team should plan differently for the upcoming 24 hours. Also, you can put them into tracking or Risk Board to facilitate reviewing further.
Option A looks good but before the conclusion, let’s see other options –
Option B – “Add the risk to the risk register and assign a risk owner.” – The question mentions using the Agile approach, and an Agile team maintains risk-related work either inside the iteration or in the Product Backlog. In Agile, the team may not create a separate risk register and assign a risk owner. In the case of the hybrid (a mix of Predictive and Agile) approach, the team can maintain a risk register, but in a purely Agile approach, it is rare. There is no indication of using a Hybrid approach in the question, so assigning and creating a risk register seems inappropriate.
Option C – “No tracking of iteration level risks is needed.” – You need tracking of risks in all approaches, be it Agile, Predictive, or Hybrid. The question is related to Agile, and in Agile, the idea of doing Daily Stand-Up is to review how the team is doing for the current iteration. And if the team has some challenge or something is not working out, it discusses how to deal with it. That’s the whole idea of the daily stand-up.
Option D – “Conduct a weekly meeting to review risks” – You should have a solid reason to add another meeting. For example, if you have a trend of many risks and need a special focused meeting, you can come up with the idea of a special meeting during the Retrospective Meeting. But even in the presence of this meeting, the team has to discuss risks during Daily Stand Up; weekly reviewing of risks is not enough.
So option A is the best choice – Make risks visible and review them in daily stand-ups.
Q43. Your team is in the mid of the 7th iteration, and you observe a recurring trend for a particular type of defect. These defects are creating rework in the current iteration.
A. Root cause analysis on these defects.
B. Start discussing defects in daily stand-ups.
C. Reserve some time in retrospective for doing root cause analysis.
D. Reserve some capacity for rework in the next iteration.
Option A – “Root cause analysis on these defects” – is best when you have a recurring trend of getting defects that create rework.
The question clearly shows that you are in the mid of the 7th iteration, and delaying it for the next retrospective or iteration, which has a current impact, may not be a good idea. The rework is getting generated in the current iteration. It is a trend, but it is also a trend in the current iteration. You can wait if the impact is not on the current iteration.
So options C and D are not suitable to solve this problem.
Also, discussing during Daily Stand up is not enough because the team need to discover the fundamental reason for these recurring defects – this discovery can come only using root cause analysis. So rather than discussing the defects during Daily Stand-up, better team allocate some time after the daily stand-up and do a root cause analysis on it and find out what they should do differently in the current iteration. So that they can minimise or avoid rework. Daily Stand up is not the ideal place to do root cause analysis; it is mainly to see what work the team should do in the next 24 hours, which can contribute to the iteration goal. So option B also ruled out to solve this problem.
Q44. Your project uses an agile approach. Which of the following technique helps in delivering value incrementally?
A. Phase End Review.
B. Deliver increment at the end of every iteration.
C. Deliver frequent Minimum Viable Products (MVPs).
D. Deliver value in Minimum Business Increments (MBIs).
This question discusses a tool and technique associated with incremental value delivery in the PMI lexicon and its terminologies. So you can pick the correct answer related to incremental value delivery. Let’s see the option and their definitions –
Option A – “Phase End Review” – The Phase end review is unrelated to the incremental value delivery. Instead, it is about checking the progress of the project to see if it is on track.
Option B – “Deliver increment at the end of every iteration” – It would be best if you deliver incremental value to the end customer as soon as possible. It could be the end of every iteration, and in some cases, it could be after a few iterations when it makes sense to the business. So, the iteration finishing and value delivery only sometimes happen simultaneously. It is not like whatever you are finishing in the iteration; it is getting delivered to the end customers all the time. So before deciding on the correct option, let’s see if you don’t have anything else, we may come back to this option.
Option C – “Deliver frequent Minimum Viable Products (MVPs).” – The Minimum Viable Product is the smallest collection of features you can include in a product for customers to consider it functional. When you have an idea for a product, you only have a little information, and you need something to test the hypothesis that customers will like it. MVP help to test this hypothesis. The MVP might be your product’s first or second release because you primarily do it for learning, not necessarily delivering value. You deliver MVPs initially to test customer behaviour, observe how the product functions, learn from it, and then move forward. That’s the whole idea. So you don’t plan multiple MVPs releases. There could be some exceptions where you end up doing 2 or 3 MVPs. But for generic understanding, you can reasonably assume you may do the first MVP, and you will learn enough, and then you move forward to deliver value.
Option D – “Deliver value in Minimum Business Increments (MBIs).” – Minimum Business Increment (MBI) is the smallest value you can add to a product or service that benefits the business. So whenever the increment you built is good enough for a business sense, it’s a Minimum Business Increment. It will help if you keep delivering Minimum Business Increments to the end customer. It could be after each iteration or after a couple of iterations per business decision.
So option D is the solution to deliver value incrementally.
Q45. One business user proposed to add a new item in the ongoing iteration.
What is the best thing to do in this situation?
A. Take an opinion from the project team.
B. Ask the user to wait for the iteration to finish.
C. Replace a planned backlog item with the new one.
D. Submit this as a change request to change the control board.
The idea of working in the iteration is that you are open to change if it makes sense to the business to deliver value. But in general, you should stick to the product backlog items you have picked up for an iteration in the iteration planning meeting and finish that iteration with that particular iteration goal. It is the recommendation. But in the real world, you may have some exceptions, but exceptions are the exception, and the question should show that there is a real need to go for it. Let’s look at options to explore the best option to see the best thing to do in this situation –
Option A – “Take an opinion from the project team. “ The project team is already working on their iteration plan. So what is the need to discuss this with them? You can consult them when you have an emergency to implement this new item. Generally, when a new item comes, it should go into the Product Backlog first, and in the next iteration planning meeting, you can explore implementing it if priority permits. So you don’t need this option.
Option B – “Ask the user to wait for the iteration to finish.” – It is a good option, but you can have a better option: ask the user to add this item to the product backlog and discuss it in a Backlog Refinement Meeting that could have been better if it is available. But this is an OK option. You can say, “Okay, let’s finish iteration,” and then we will see if you want to take this particular item. Provided the other priorities are also matching, we flag this option B. We will return to it if you still need to get something good.
Option C – “ Replace a planned backlog item with the new one” – You don’t do that. So if you have to handle these things well, you only look for this adjustment in exceptional situations. So instead, you focus on let’s put it into a backlog, let’s discuss in a Backlog Refinement activity. So there are better ideas than option C.
Option D – “ Submit this as a change request to change the control board.” – In most cases, requirement-related changes will not go into a change control process; instead, they will go into a Backlog Refining process. Exceptionally there could be change management in an agile world as well. You can have some changes requiring change Control Board intervention and define it in your overall project management plan. But for requirements, Backlog refinement is your Change Control Board.
So looking at the remaining options, option B is the one which probably can work.
You can tell the user to wait for the iteration to finish. The B hints that we can pick it up in the next iteration, but that is not always true because it also depends upon what other items are coming in. But making the stakeholder user wait for the iteration is the best option out of the available ones. So we go with option B- Ask the user to wait for the iteration to finish.
Q46. Your teams analysis of MVP released last month shows that 5 out of 7 hypotheses are invalid. What do you advise to do next?
A. Recommend backlog refinement with new learning.
B. Recommend further analysis in retrospective.
C. Recommend stopping the project
D. Stop the current iteration and do replanning.
The team released a Minimum Viable Product (MVP) in this question. MVP is the smallest collection of product features to consider the product as functional to test the hypothesis or assumptions. You hoped the customer would behave in a particular way and use the product in a specific way, which can serve customers’ needs. But based on the observation and the uses pattern, you realise that only some users used the product in that particular way. And many of the possible target customer segments are not even looking at the MVP. Now, this is learning where the team need to change direction. Else, it might result in stopping the project. The team must recreate the hypothesis with the new learnings and check if the modified approach works. That is the one possibility, or the team may change the whole direction of the product offering or a customer segment called the pivot. So it’s a turning point. The team need to do something about it.
Option A looks promising in this situation, which recommends backlog refinement with new learnings so that the team has a new way of looking at the customer needs. Backlog refinement may result –
Let’s see why other options are not suitable for the solution –
Option B – “Recommend further analysis in retrospective.” – Retrospectives are more associated with the learnings coming from the team. In this learning process, you also need external stakeholders. You might do a special retrospective meeting for it, but you have already done the analysis and now need to act on it. Further analysis may produce some refined learnings. The question is saying do something about it, better act on it.
Option C- “Recommend stopping the project” – It could be possible, but we do not see an evident judgement in the question that this is something hopeless or you’re investing in the wrong place.
Option D – “Stop the current iteration and do replanning. “ – It is possible, but what should you do before doing that? First, it would help if you had a refind Product Backlog before that, so you probably focus on option A first.
Q47. A Stakeholder experienced in predictive methods asks where to find the escalation process in adaptive life cycle projects.
A. The communication management plan of the project defines the escalation process.
B. Iteration review meeting takes care of escalation.
C. Daily stand-up meeting takes care of escalation.
D. The escalation process does not exist in the adaptive life cycle.
In every project, even in Agile, you have formal communication needs, a contract to take care of, and some set of stakeholders to communicate various information based on their needs. So, in a project context, things like the communication management plan, stakeholder engagement plan, and quality management plan remain valid even if you are working in Agile. For example, the team usually put escalation-related communication in the communication management plan. So, please don’t assume that you don’t need communication management or stakeholder engagement plans in Agile. They are needed.
So option A is the correct option.
Now let’s go with options to see why they are not suitable to take care of escalation-
Option B – “Iteration review meeting takes care of escalation.” – Not necessary. After iteration, you do the iteration review meeting to review and learn what you have developed based on previous understanding and discoveries. You demonstrate and take feedback from stakeholders to identify learnings to move forward in the next iteration; that’s the whole objective. So if something requires escalation, you do not need to wait for the iteration review and make it an agenda item in the iteration review, so, not necessary.
Option C – “Daily stand-up meeting takes care of escalation.” – The Daily Stand-up meeting is primarily for the team, so escalating during the Daily Stand-up might create more confusion than value. So instead, the Daily Stand Up focuses more on figuring out how we are doing in the current iteration and what we should do differently to meet our iteration goal. That’s the whole idea of a daily stand-up meeting.
Option D – “The escalation process does not exist in the adaptive life cycle. “ – You must also take care of escalations when working in a project space.
Q48. Which of the following is NOT part of product backlog refinement activity?
A. Prioritization of the backlog items.
B. Estimation of the backlog items.
C. Splitting of large backlog items.
D. Identification of implementation tasks.
Before the iteration planning meeting, the team needs a prioritized product backlog where high-priority top items are small-size, and less-prioritized later items can be big in size. Top Product Backlog items are ready to go in the iteration backlog, which means –
Also, Product Backlog items are emergent, so based on learning from iteration to iteration team keeps redefining Product Backlog items –
So, the team needs to relook at the Product Backlog to keep Ready top product backlog items for the next iteration. And do other refinement activities like adding, removing, re-assign relative priority, splitting big-size into small-size, and estimating product backlog items. The team does all these activities in the Backlog Refinement Meeting. They do this meeting preferably every week and before the iteration planning meeting to ensure the Product Backlog is orderly and clean.
So the team does Prioritization (Option A), Estimation (Option B), and Splitting of large backlog items (Option C) during Backlog Refinement Meeting. So option D is the right option because the team does not identify implementation tasks in the Backlog Refinement Meeting.
Q49. Your team released the second MBI last week, So one MBI was before and last week you will release the second Minimum Business Increment resulting in many unexpected enhancement requests.
What is the best way to handle these requests?
A. Add them into the product backlog.
B. Create a change request for these enhancements.
C. Stick to the current release plan. Because they were unexpected requests.
D. Include request in the current iteration postponed other work.
Option A is clearly a safe option you can definitely pick up as the right answer.
Let’s see what is wrong with B, C and D.
Option B talks about raising a change request. In Agile, the Product Backlog Refinement should take care of such changes. So, because the change request for enhancement does not make sense, you can keep option B out.
Option C says to stick to the current release plan. The question indicates that you have an unexpected request, but in the agile way of working, you need to look at the new learning. It would be best if you keep revisiting the plan. So, sticking to the current release plan for MBI 3 is not a good idea. You may decide not to work on these enhancements, but you need to look into that.
Option D asks to include the request in the current iteration. The question does not indicate that this is something you must do it now. You only do such things as an exception where the business says they need them now, or it will impact the business. But here, we don’t see that kind of situation arising.
So it’s simple, add the new enhancements to the Product Backlog. Now addition does not mean that team will work on them after this iteration, or the team might work on them. There will be proper refinement based on the priority, and the team will involve the appropriate stakeholders in this activity. So, based on the refinement process, the team will work on these enhancements.
So for this question, you can safely pick up option A – Add these enhancement requests to the product backlog.
Q50. Some stakeholders are unhappy about your teams priority in the current iteration.
What is the best thing to do in such a situation?
A: Proposal replanning of the current iteration.
B: Explain the prioritization process and ask for feedback.
C: Assure stakeholders to include their priorities in there in the next station.
D: Ask the stakeholders to raise a change request.
Let’s see the project scenario in detail –
You are running in a current iteration, and a few stakeholders tell you that whatever you guys picked up for this iteration is not the proper priority. And it would be best if you were working on something else. Such things are common because there are many stakeholders in a project, and you need to take the best possible priority, which is coming out from your Backlog Refinement process, and the team get started based on that. So you have done Backlog Refinement. Still, people are unhappy about it. Now, in question, there is no apparent need coming in, which is saying that these stakeholders are the ones who are right. They might have their opinion, which you want to understand. So proposing planning the current iteration and disturbing it isn’t the right thing to do.
So option A, which is about replanning the current iteration, is unsuitable.
Option B suggests explaining the prioritisation process and asking for feedback. That is a good option. You need to explain the overall iteration goal and how the team selected items based on that. But you may need to review the prioritization process. Based on feedback, you may realize that the current stakeholder group participating in the backlog refinement meeting may not represent the stakeholders you need in the Backlog Refinement process. So you need to understand the stakeholder engagement plan. It would be best to see who the stakeholders are and who needs to be engaged more, which might result in your backlog refinement process becoming more consulting with those stakeholders.
Now option C says to assure stakeholders to include their priorities in the next iteration. But, unfortunately, you can’t keep that promise as such patchwork is not a good idea team relook priorities in the backlog refinement process.
Option D says to ask stakeholders to raise a change request. In Agile, requirements are emergent and submitting a change request is not needed. However, you may need a change request for purposes other than requirements that you can identify as per our change management plan.
So looking at whatever is available in this question, option B is good.
