Mehran BagherianControl and Instrumentation Engineer| RV AndersonNorth York, Canada
Obviously, the acceptance criteria for any deliverable product/service in a project, are expected to be able to be achieved, measured, and proved to the customer. However, there are circumstances that the requirement are sort of subjective. How this kind of requirement can be validated when come to acceptance criteria? Saving Changes...
That is why many people use the SMART acronym to evaluate acceptance criteria - if it isn't specific & measurable, then it is open to interpretation.
I'd suggest further refinement of the acceptance criteria are required to get them to be as objective as possible.
Kiron
...
1 reply by Mehran Bagherian
May 27, 2020 1:49 PM
Mehran Bagherian
...
Kiron, Thank you for your comment.You are correct. Imagine you are managing of a software development project, and your customer does not like the appearance of the user interface. They may not like the color, or the design, etc. And they request you to modify it, but does not lead you to their goals perfectly, as they don't really know what it would be, they just know they don't like it, and you continue correction and this is going on and on. You don't want the scope creep, you need to close it anyway, what do you do here? This may be defined in agile methodology. A metric like number of user stories, or something.
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Mehran
you could say all requirements are subjective, since they are imposed by stakeholders, humans. Each one of them. And humans may have different perspectives on the same requirements.
Some requirements are codified in laws and regulations, or contracts and agreement, which makes it easier to commit to acceptance criteria on both sides.
For the others we have to have this discussion, negotiation and mutual commitment what the acceptance criteria are. Some can be part of the Charter, others of the project management plan, scope definition. Saving Changes...
Mehran BagherianControl and Instrumentation Engineer| RV AndersonNorth York, Canada
May 27, 2020 12:25 PM
Replying to Kiron Bondale
...
That is why many people use the SMART acronym to evaluate acceptance criteria - if it isn't specific & measurable, then it is open to interpretation.
I'd suggest further refinement of the acceptance criteria are required to get them to be as objective as possible.
Kiron
Kiron, Thank you for your comment.You are correct. Imagine you are managing of a software development project, and your customer does not like the appearance of the user interface. They may not like the color, or the design, etc. And they request you to modify it, but does not lead you to their goals perfectly, as they don't really know what it would be, they just know they don't like it, and you continue correction and this is going on and on. You don't want the scope creep, you need to close it anyway, what do you do here? This may be defined in agile methodology. A metric like number of user stories, or something.
...
2 replies by David Portas and Kiron Bondale
May 27, 2020 2:35 PM
David Portas
...
The key is to collaborate with the customer and demo as early as possible to get their feedback. Your definition of done should include reviewing the UI with the customer so you avoid those "scope creep" problems or at least catch the issue very early so that the debt doesn't accumulate
May 27, 2020 3:44 PM
Kiron Bondale
...
Short feedback loops, prototyping and engaging the customer in the requirements and design process are all ways to make the conceptual tangible.
You need an agreed owner/approver to make the call on acceptance. Customer satisfaction usually trumps objective criteria (excepting cases of science, regulations and the law). Saving Changes...
Kiron, Thank you for your comment.You are correct. Imagine you are managing of a software development project, and your customer does not like the appearance of the user interface. They may not like the color, or the design, etc. And they request you to modify it, but does not lead you to their goals perfectly, as they don't really know what it would be, they just know they don't like it, and you continue correction and this is going on and on. You don't want the scope creep, you need to close it anyway, what do you do here? This may be defined in agile methodology. A metric like number of user stories, or something.
The key is to collaborate with the customer and demo as early as possible to get their feedback. Your definition of done should include reviewing the UI with the customer so you avoid those "scope creep" problems or at least catch the issue very early so that the debt doesn't accumulate Saving Changes...
Kiron, Thank you for your comment.You are correct. Imagine you are managing of a software development project, and your customer does not like the appearance of the user interface. They may not like the color, or the design, etc. And they request you to modify it, but does not lead you to their goals perfectly, as they don't really know what it would be, they just know they don't like it, and you continue correction and this is going on and on. You don't want the scope creep, you need to close it anyway, what do you do here? This may be defined in agile methodology. A metric like number of user stories, or something.
Short feedback loops, prototyping and engaging the customer in the requirements and design process are all ways to make the conceptual tangible.
Subjective requirements are often necessary but they are a source of systematic risk. Mitigating that risk requires carefully tailored processes for both validation and verification (validation being are the requirements correct, and verification being have they been met).
Consider a transportation requirement that the vehicle does not contain any known hazard. What does that even mean? It's not possible to list every possible hazard, so instead the regulator may include detailed written guidance for how the requirement is assessed. The same can apply to major milestone criteria within a company where a requirement "All Interfaces Complete" may have several more detailed sub-tier criteria to elaborate.
The next big issue is who decides whether or not the criteria were met. It may be defined in the contract, but there may also need to be SMEs on specific knowledge areas. It is extremely helpful if you have a 1 to 1 one relationship with the experts on both the customer and supplier sides, and an arbitration process. Those people should agree during the planning stages as to how verification will be demonstrated rather than finding out later when changes are far more expensive.
When dealing with regulators, one consistent issue is that the reviewer on the regulator side changes to a different person, who has a completely different perspective than the prior reviewer and throws out the original plan late in the game. People may change jobs, but efforts to avoid a different set of reviewers each time can be very helpful. Saving Changes...
The key to subjective are the keep engaging customer define the expectation. This is well covered when we talk about the Agile way of working. The development is taken step by step and customer is involved the discussion for each step development. The requirement is covered as part of user story and so that most of the possible requirement and imaginations are covered as part of defining the requirements.
So Agile is the solution which might fit here better. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
If you accept an acceptance criteria to be subjective you are lost, except it is for a well defined strategy. For example, in much cases, to sell something aditional or to open a discussion because the organization know some items will not be created as needed. Saving Changes...
