Team

Overview

Unknown value of product backlog

Improve product backlog and size

Put the Product Owner in the contract

Put The Product Owner in the Contract BEST PRACTICE – The ‘Pre-nup’ 1.0 The customer must provide an empowered representative ‘The PO’ who: 1.1 Is responsible for providing and maintaining a list of prioritised requirements, which they can change at will. 1.2 This shall be on the only plan. 1.3 Will remain intheir position and operate with freedom regardless of client/supplier relationship status. 1.4 The PO will be told how many sprints are left before every sprint so that they can prioritise accordingly. WHY DO THIS? To avoid the PO being emasculated The PO has complete ownership of the only plan The PO can continue to function at a time when client/supplier relationship threatens delivery of goals/outcomes

Avoid delusion about progress

Practice 1: Customer needs to understand the benefits of the prioritised backlog to be aware of project completeness as stories are completed.

Prioritise backlog according to criteria that allow insight into actual progress. Value and risk are common criteria.
Doing the easiest items first is unlikely to give you the ones that you need to have working software.

Practice 2: Use a Definition of Done (DoD) that avoids rework

Often, the sprint increments are not shippable. Work is postponed, thereby creating a “hidden backlog”. Kinds of work that are often postponed: defects, acceptable performance, integration with other parts of software, integration with 3rd-party services, deployment, testing.
A DoD that forces you to pull up these work items supports a realistic measure of progress.

Practice 3: Provide the customer with continuous visibility into project progress.

This enables both parties to recognize deviations early on.
Thereby they avoid divergence of expectations and a build-up of risk.

Practice 4: Ship intermediate releases to prove progress towards functional product.

This enables the the team to be focused on deliving functional work.
At certain points/milestones a release could be made from current progress.
This pulls up risks and forces both parties to face the reality.

Practice 5: Demo progress to customer even if not ‘Done’ but highlight this a not complete.

Don’t postpone showing software, however incomplete, until the release.
This allows for earlier feedback on the parts that have been done.
In every specification there is room for interpretation. Demoing what is there avoids a divergence of expectations over time.

Practice 6: Highlight what is not done as part of sprint review.

Stop people believing that the story is complete when it is only graphically complete.
Clearly defines the level of completion of the story.
Show status of the story to highlight outstanding work.

Accept changes even in an agile fixed price contract

Understand how changing requirements are modeled instead of classic claims management
Be assured that agile change management does not disfavor one party imbalanced.
Changes must not impact running sprints.
Changes coming in for future work are very welcome – they must be balanced by reprioritizing other items => e.g. achieved by equal sum of story or value point
Balanced dynamic use of overdrawable story point account
Possibilities (see also “10 Contracts for your next Agile Software Project“):
- Fixed Price per sprint
- Change for free
- Money for nothing
- Scrum on steroids

Why we should do it?

Clear and agreed rules and hopefully established standards for negotiations

Smells and Symptoms

Endless discussions in plannings/reviews indicate missing or vague clauses in the contract

Risks

• Ending up in court

Fundamentals for DOD in the contract

Try to focus on non functional requirements (NFR)
Refer – where possible – to appropriate norms (DIN/ISO/IEEE standards)
Allow only clauses that are objectively justifiable and match Scrum team domain expertise
List of DOD items that must go
- DODs of the development process (clean code, architecture, source code documentation, user documentation, … )
List of DOD items that must not go
- Items increasing the risk of liability are unwanted by the purchasing party
- Items not fitting in the Scrum team domain expertise are unwanted by the selling party
List of DOD items which are subject to negotiation

Why should we do it

“When the shit hits the fan” … DOD is crucial
Before and in escalation takes place … clear rules are stated

Smells and Symptoms

Over selling by the sales department results in DOD clauses which do not match with scrum team domain expertise
Locking the team too much into rules

Risks

No DOD => endless discussions on individual story basis
Sloppy DOD => too much room for interpretation#
To detailed DOD
- too much effort with respect to the effort of writing the contract
- over-regulation of the process

Relevant reference: podcast by Gabrielle Benefield.