Developers have an issue with the Acceptance Criteria
I am new to being a scrum master. The Dev team produces the product based only on the acceptance criteria, however, when their code is reviewed by the architect, the code logic is not there. I was informed stories are not implementation details. They look for implementation details in Acceptance Criteria.
EXAMPLE:
Story: As a user, I would like to see my farmland records displayed in a table so that I can see the total acreage of each farm displayed
ACCEPTANCE CRITERIA:
- Query farmers name
- Display query results
- results should show farmer's name and acreage of each farm
What it wouldn't say is:
- The acreage calculation should use unit of feet not meters
- Acreage calculation is not 2D it's incorporating 3D calculations... so factoring in the hills, slope, valley. etc...
I've checked online to see if others have encountered this, but people mention the AC needs to be verbatim. Is that accurate?
What matters is that people talk with each other and evolve requirements -- such as user stories and acceptance criteria -- as they jointly figure out the best way to build a complex product.
Developers do not slavishly follow instructions verbatim, nor are they left to flounder until some external authority reviews things. Collaboration is key.
User Stories and Acceptance Criteria are not meant to provide detailed specifications. They are meant to provide enough information for people to understand the work that is needed in context to the product. If the product usually calculates acreage in feet, then it should be understood that it will continue to do that.
Is the architect complaining about the user story content or the actual solution being provided by the developers? If it is the user story, see my comment above. If it is the actual solution then it appears that the Scrum Team is not doing an adequate job of refining the stories before they start working. Refinement provides the details necessary to fully understand the work that is being requested. It appears that the architect has some details that might not be shared with the developers.
There are no "standards" for User Stories or Acceptance Criteria. The best ones are the ones that work for the people using them. And the Scrum framework does not even mention their use in the Scrum Guide. They were first used in eXtreme Programming and didn't include acceptance criteria at all. So everything you are reading about the "correct way" is just some person's opinion. As a Scrum Master for the team, work with them to determine what is best for them. If the architect is responsible for the work that is being done, then they would be considered a developer by the Scrum framework and should be included in the discussions.
That's right! By encouraging conversations between Product Owners, Developers, and Architects, you enhance collaboration. By moving away from strict adherence to detailed instructions and fostering dialogue, developers can feel more empowered to take ownership of their work. This in turn, boosts motivation and innovation for future situations.
Where is the conversation about the work between the Developers and the Product Owner, or, perhaps, directly with stakeholders? Where is the Product Backlog Refinement happening?
Someone may write descriptions of the work and hand them over to Developers. If there were conversations about this work, especially with Developers who understand the problem domain, I would expect questions about what units or formulas to use.