In this tutorial, Saket Bansal illustrates

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.

Answer: 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 and these requirements are listed in the Product Backlog in a prioritized manner.

Typically product requirements are expressed in the form of user stories in a Product Backlog, but it is not mandatory. You can use other tools as well so it’s not a must to use User Story. Many assume that there have to be user stories in the product backlog, but in the agile world user story is one of the tools for exploring requirements.

Also, apart from user stories (small size requirements), Product Backlog can contain other things; like:
Large size Requirements typically known as Epics
Issues to be resolved
Technical work,
Knowledge needs for the team, and
Other research work related to product development.

Each of the above items describes requirements which project team needs to do to fulfill user wants related to the product.

Option A – “ Product Backlog is a collection of User Stories” – The Product Backlog definitely contains user stories, but it can contain other things as well like epics, issues to be resolved, knowledge acquisition, technical work, and other research work related to the product development.

In absence of option D, this could be marked as the right option.

Option B- “Product Backlog contains the project scope” – Product Backlog is the prioritized list of requirements, it does not describe 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 are we going to 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

Answer: B
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; many times they get new ideas to further improve the product, and sometimes they feel work could have been better. It is quite common that these feedbacks result in the discovery of new acceptance criteria to existing user stories. Discovering 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 pen down items that need to be added to the Product Backlog. You can call it an Incremental Requirement or incremental Acceptance Criteria to 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 iteration Review meeting team shows work which is completed based on Definition of Done. Meeting Definition of Done also makes sure that all agreed acceptance criteria for user stories are done. So, for the acceptance criteria which are just been discovered, there is no need to mark Done User Stories undone. If you keep opening those user stories just based on the feedback then 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 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 clearly loses the sense of accomplishment even the work was done 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, the discovery of new acceptance criteria to a user story is common and as all newly discovered items go in the Product Backlog, we can create new Product Backlog items with incremental exploration.

In summary, we can consider this option as a candidate option for marking the right option.

Option C – “Perform a root cause analysis on missing acceptance criteria” –

This option says if during 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 it as an exception.

But if you have a trend of such discoveries in the iteration review, then it triggers that you should 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 who 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.

You are briefing about the agile approach your project is following in 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 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 if everything is working as per specification? – it is a verification activity, not a validation. Scope validation is an activity to check if the completed work meets the purpose? – that is something the business or end-users representative can only do. In Agile, stakeholders and product owners look at the product and see – Are we meeting requirements as intended?
That’s the whole idea about validation, so option B is the wrong option.

After discussing option B, option A also came out as the wrong option. A solution validation has to happen irrespective of the selected project approach be it is predictive or Agile way of working.

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 on 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 in your product backlog, refine them as per prioritization, and do it as per priority.

Kindly note; you do not necessarily have to wait for an iteration review meeting for the validation. 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 are targeting something else rather than validating scope in the agile context.

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 is primarily focusing 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 serves the purpose of clarifying business requirements/conditions for a product backlog item. Each product backlog item must meet their agreed acceptance criteria to mark it 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 mark completeness of deliverable. Therefore; the Definition of Ready is not the right option.

Option C – “Iteration Review” – In the iteration review meeting, the team presents the completed work to key stakeholders. When stakeholders see this usable piece of work, they check “Are these deliverables good enough for us?” So this option is also a candidate option to mark it right.

Option D – “Definition of Done (DoD)” – Definition of Done helps the team to have a common 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 rather 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. This 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, which means the team completed it as per the agreed understanding of completion of the deliverable.

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. Question is – How in agile do you control scope? or Which of the following tools can help you in controlling scope?

You can say, controlling Scope means, you are doing –
What you have agreed upon and as per the priority, and
Following a way or a structure which you have agreed to explore the scope. You are not bypassing the backlog refinement and the Definition of Done
Now, let’s look at each of the options –
Definition of Ready: it helps in identifying how much product backlog item should be ready enough 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.

Definition of Done: It helps the team for a shared understanding of product backlog item completion. It is a kind of checklist of items that each product backlog item must comply with before it is considered complete. It gives a clear idea of the number of things you should be working on for a particular product backlog item. Hence, DoD addresses the gold plating because it helps knowing items you should do to make the client happy. Understanding client happiness is not based on team judgment. So, I believe this is one of the right options out of 2.

Daily stand-up meeting: It helps the team to gain an understanding of 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 end up discussing some scope-related items, but they do not directly contribute to control scope or gold plating. So, this is not the correct option.

Continuous stakeholder engagement: In agile, you encourage the team to interact with the stakeholders continuously as it helps with the inspect/adapt regularly. It is unlikely that you start work, and after a pretty long time, you come back to show the completed work. Instead, you do the iteration review as the iteration goes on. In other words, you show 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 in controlling scope (both scope creep and gold plating) as it ensures work progress as per the agreement and as per the priority

In summary, both continuous stakeholder engagement and agreement on the Definition of Done help in the control scope. So, options B, and D are correct options.

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 be defining it?

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:
The product owner and the customer may help define acceptance criteria for each product backlog item. When team members get the knowledge, they also contribute to defining acceptance criteria. Kindly note that Definition of Done ensures you also meet the acceptance criteria of each product backlog item. So, DoD also includes you meeting the acceptance criteria of each product backlog item.
The team is responsible for the quality of each Increment. The team has the most knowledge about the technical and quality aspects of the product

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 useful 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” – 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 – “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.

Which of the following best defines the User Story?
A. User Stories defines the requirement in 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 point of view. User story communicates what a user wants to do that 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 prioritized list of all the requirements, so if any requirement is non-key it will be deprioritized in the product backlog.

Option D – “ User Story defines the product goal.” – User story is not about defining product goal. It defines 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.

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.

Answer: C

Let’s first explore what is Requirement Traceability Matrix –
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 are meeting the business purpose.
We can put requirements in the middle of the grid & there could be a forward as well as backward traceability.
For each requirement in the grid, when we go back and see why this requirement is needed? What kind of business objectives is getting met by implementing this particular requirement? Who needs it? What is the source of this particular requirement?
Sometimes, a stakeholder comes and says, why do we have this requirement? What value it is adding? So you can go back, look at the requirement source, and give those answers. Here, RTM works as a handy tool to say why do we need a particular requirement?
If we go in a forward direction – we see – what are we doing in our solution to implement this particular requirement? Which deliverables are taking care of it? Which design will support it? Which test will test it? Which particular document is elaborating it. – Because there could be a situation when you want to know more about a requirement.
Requirement Traceability in Agile:
Traceability is needed in each project. But, in Agile projects, an explicit Requirement Traceability Matrix is not needed to ensure we are meeting requirements. Tracking of requirements is there organically. You can see traceability from the product backlog to sprint backlog and finally to the increment produced. The Product Backlog is a prioritized list of all the requirements and this priority directly reflects the project vision and goal.
Also, using iteration review you frequently show work to stakeholders, so you are doing validate scope frequently to see if the increment is serving the purpose. In this way, we may not need a separate document to track requirements. You may need to create a separate RTM document even in Agile projects to adhere to compliances if any, but in general, an explicit document is not needed.
So option C is the best answer – RTM is usually not needed

Now, let’s look at other options just to clarify, how well you got an idea related to the Requirement Traceability Matrix.
Option A – “ RTM is part of the Definition of Done” – DoD is a kind of checklist to mention technical and business quality requirements that must be met before any product backlog item is marked complete. The purpose of RTM is to track if requirements and respective deliverables are meeting the business purpose. So how can an RTM be a part of the DoD? It is a 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 traceability of 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. We don’t have a dedicated guy who is expected to do a Requirement Traceability Matrix preparation. The product owner is expected to discover the product backlog and prioritize it, but not necessarily prepare the requirement traceability matrix. So this is the wrong option.

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”. This is the definition of an epic. Epic is a large size requirement that 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 may extract three stories out of it in the next iteration, then develop it.
You may start splitting multiple stories in one go, but not necessarily follow all the time.

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 idea of the agile way of working with the requirement is progressive elaboration. You should not elaborate 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 months in advance or 6 months in advance. Because, if you do that, whatever you have worked this week or next week or 2 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 the things done.

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.

Answer: 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 –
For the challenges; the team is facing to develop user stories
For more clarification, the team needs about user stories
To add or remove acceptance criteria to the user stories as new information uncovers.

So user stories are not a contract are conversation starters instead. It implies flexibility and empowers the team to question the requirements even after work started on those user stories. The product team should be able to revise the story as soon as new information uncovers.

In summary, there is never late to talk about if something is going wrong in a given user story. It is never late to get some clarifications related to the user story. Iterative development is not about a silo’s approach or a baseline approach –
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. You never do that. So, once you understand that collaboration can happen all the time, 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 then 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 for a given situation. Yes, the team can talk about this situation in a retrospective meeting if these things are happening very frequently. But as of now, when the team discovers it, they should quickly discuss it for the earliest possible opportunity with the product owner.

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 coming Sunday using a calendar
Story 2: As a frequent traveler, I want to see my reward points balance to plan the usages.
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?

.Stories 1 and 2 are INVEST
Stories 2 and 3 are INVEST
C.Stories 1 and 3 are INVEST
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 just looking at this user story. Sometimes you may not have an independent user story, but you should always aspire to have them.

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 be fitting in a given iteration.

Testable: T stands for Testable. A well-refined user story with associated acceptance criteria and objective terms makes it testable.

Let’s see user stories one by one –

Story 1: As a user, I want to be able to select 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 is the user? How is adding value to the user?
Also, this user story could be independent, or it may not be independent because you might be selecting the calendar to get something done. It’s just not like you select a calendar on Sunday, and something happens.

It is not an INVEST user story.

Story 2: As a frequent traveler, I want to see my reward points balance to plan the usages.

Following are the observations for this user story –
It explains – A frequent traveler (User) wants to see reward points to plan usage. (value). It means this user story clarifies – who is the user? And, what value does this user get?

It seems to be a small requirement, but it is not easy to predict just by looking at this particular user story.
It looks to be a well-testable user story because if you have this feature done –
You should be able to test – If I can 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. So, it looks like an INVEST user story that is independent, small, estimable, and testable as well.

User stories 2 and 3 are good. You may not 100% 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 have to remove that particular 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 has 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?

Work with stakeholders and take formal, detailed feedback
Work with the Product Owner to ensure the requirement prioritization
Revisit Definition of Done
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 one 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 prioritization” Here, it is clear that requirement prioritization was missing, so the Product Owner should fix the issue related to the requirement prioritization. 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 meeting, usually team does retrospective meeting which is a good place to talk about feedbacks 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 which happened in the previous iterations and come up with the 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 back to see what went wrong and what has to be improved, so requirement prioritization 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. Because such conversation might result in more collaboration of team with 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, the Option D option looks like the best thing to do as the next step. Sometimes you have more than one possible action for a given situation, but you need to identify which one is the best.

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 does not have a proper understanding of project requirements. Apart from that, the team also does not have any access to validate the solution. So, learning through actual usage is the only option here 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 when there is requirement uncertainty, we never do requirement analysis.
Option C – “Develop the product based on similar competitor products.” – It could a possible option when requirements are not clear. 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 first can 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 as per the hypothesis, the team learns how users respond to it? Using this learning team decides the further direction of the development. So, 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 these items are not detailed enough 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:

Definition of Ready defines pre-conditions for product backlog items or user stories. These pre-conditions need to be fulfilled before user stories are allowed to go into the Iteration Backlog. Meeting these pre-conditions ensures that the team does not pick unrefined user stories into the iteration; they pick only ready user stories.

A user story is ready to work in an iteration only when –
Team members have a shared understanding of the user story, and they understand its work to a good level
Enough acceptance criteria are defined for the user story to ensure testing, and
User Story is small enough to complete in one sprint

In other words, Definition of Ready makes sure that 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 only when they see –
That these user stories fulfilling the criteria of Definition of Ready. Fulfilling Definition of Ready pre-conditions requires backlog refinement activity. It is encouraged that the team does 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 the refinement of 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.