N is for negotiation.

When you talk about successful Agile teams, everything begins with writing user stories that the team can execute during the sprint. If that does not happen, a team is left drifting in calm seas with no wind. Last week, I began my series on the INVEST model of story writing, and today I will explain why user stories need negotiation.

The Myth of Magic Software

Plenty of people think that software is a magical process. All you need to do is provide coffee and pizza for a group of gifted nerds, and within a few hours you will have software. The reality is disappointing. Software requires time, money, and effort. The enterprise the software resides in, the type of database used, and now, the large language model required to get the work done have upsides and downsides. So, getting things into production requires a continuous process of trial and error.

The vague ideas in a sales or marketing professional's mind do not account for factors such as memory, network latency, and data structure. The same is true with UX/UI design. A static Figma or PDF mock-up cannot simulate real-world constraints like network latency or varying viewport sizes. Code that might work on an Android phone might look weird on an Apple device. Web pages behave differently in Chrome than in Safari. All of these constraints and nuances must be accounted for in a story. Nothing will be perfect, but negotiating between the stakeholder and the development team might create an outstanding product.

Case Study: Negotiated Acceptance Criteria

Here is an example of a user story that must be negotiated.

"As a case worker, I want to enter initial assessment data into the system so that I do not have to duplicate handwritten notes into the digital portal."

The first question a developer asks when they see this story is whether it needs to be a mobile app. More people know how to code web applications than mobile applications. If the stakeholder says it must be a mobile application, that opens a series of concerns about development and testing. The development team might also ask whether we need mobile apps for both Android and Apple devices, or whether the company issues phones to case workers, which would limit the number of code variations required across all phone makes and models. After collaborating with the developers, the product owner refines the story and adds additional acceptance criteria.

Scenario: Android Access
  Given I have an Android phone
  When I select the shortcut on the home screen
  Then I view the application in the Android Chrome browser
  And the screen resolution should be displayed cleanly at 320px width
  
 Scenario: iPhone Access
  Given I have an iPhone
  When I select the shortcut on the home screen
  Then I view the application in Safari
  And the screen resolution should be displayed cleanly at 320px width

The Power of Negotiation

Thanks to negotiation, the project moved faster, and a team of in-house developers was able to complete the work without paying extra for a mobile development boutique to build a mobile app.

Requirements are never set in stone or immutable. Instead, they are the product of give-and-take between the development team and the people commissioning the work. Otherwise, you will be dead in the water.

Until next time.