- Javier Espinosa
- Cameron Ramsay
- Warwick Bambrook
- Russell Murray
- Ben Maynard
- Boris Kneisel
- Gernot Stocker
- Mehmood Hasan
- Alex Bepple
Unknown value of product backlog
Improve product backlog and size
Put the Product Owner in the contract
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
• 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
- 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.