Downloaded 29 times
![Example of a user story
As a [role], I want [goal/desire] so that [benefit].
As a traveler I want to find my seat in a bus so that I
can change it.](https://image.slidesharecdn.com/agilecontracts-150219084147-conversion-gate02/85/Agile-contracts-9-320.jpg)
Uploaded byElina Jakubaneca
Agile contracts
The document discusses agile contracts, emphasizing the importance of clearly defined user stories, scope of supply, and customer involvement in projects. It outlines the necessity for easily understandable payment terms, project governance, and a change implementation procedure while ensuring that software is potentially shippable at the end of each iteration. Additionally, it provides guidelines for creating effective agile contracts, including gathering user stories and agreeing on deliverables and acceptance procedures.
More Related Content
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
Agile contracts
- 1. AGILE CONTRACTS Presentation isbased on real-life events and personal experience
- 2. Supplier’s scope ofsupply Project plan Price and payment terms Customer’s scope of supply Quality requirements Change implementation procedure Delivery and acceptance Project governance Legal frame
- 3.
- 4.
- 5.
- 6.
- 7.
- 8. Describe scope byusing user stories or in other agile software development friendly way with clearly described expected outcome.
- 9. Example of auser story As a [role], I want [goal/desire] so that [benefit]. As a traveler I want to find my seat in a bus so that I can change it.
- 10. Initially a contracthas to contain the least possible scope, that gives added value to a customer.
- 11. Each user storyincluded in a contract need to have an estimate in complexity points or mandays.
- 12. PRICE AND PAYMENTTERMS
- 13. Payment terms needto be easily understandable and acceptable by all involved parties. agile ≠ time/material
- 14.
- 15. Contract has tocontain detailed description of a customer’s involvement requirements in a project.
- 16.
- 17. In the beginningof a project there is at least one iteration (sprint) needed for preparation works.
- 18. During a projectthere is at least one iteration (sprint) needed for acceptance testing.
- 19.
- 20. Project governance isdescribed as part of customer’s scope of supply and change implementation procedure.
- 21.
- 22. Software has tobe potentially shippable at the end of each iteration (sprint).
- 23. System testing isperformed during each iteration (sprint).
- 24. Acceptance testing isperformed during a separate iteration (sprint).
- 25.
- 26. Contract has tocontain short and clear description of user story replacement principles.
- 27. WHAT HAS NOTCHANGED?
- 28. Legal frame Quality requirements Supplier’sscope of supply: a) non-functional requirements (for example, technology requirements, integration requirements) b) support and maintenance of functionality in production
- 29. HOW TO MAKEYOUR OWN AGILE CONTRACT?
- 30. Together with a customergather user stories for least possible project scope that brings value to a customer Gather non- functional requirements Agree with a customer on software development approach and explain involvement requirements 1. 2. 3.
- 31. Agree with a customeron needed deliverables and acceptance procedure Agree with a customer on price and payment terms Prepare a legal frame 5.4. 6.
- 32. Sources of inspiration AgileContracts by Alistair Cockburnhttp://alistair.cockburn.us/Agile+contracts Agile Contracts by Tom Arbogast, Craig Larman, and Bas Voddehttp://www.agilecontracts.org/agile_contracts_prim er.pdf Scrum guide (in Latvian)http://www.autentica.lv/lv/article/scrum-celvedis- latviesu-valoda/ original (in English) http://www.scrumguides.org/scrum-guide.html
- 33.
Editor's Notes
- #3 Typical software development contract consists of: 1) legal frame – part of a contract which contains general information about a project and contains references to attachments; 2) supplier’s scope of supply – functional and non-functional requirements of a solution; 3) Price and payment terms – price and terms when and how it is paid; 4) customer’s scope of supply – material and non-material deliverables, which a customer has to supply; 5) quality requirements – measurable requirements of a software solution (e.g, performance requirements, requirements towards number of known errors); 6) project plan –activities required to meet project goals scheduled in time; 7) project governance – the way how a customer and a supplier will keep control over a project; 8) delivery and acceptance –project deliverables and their acceptance criteria; 9) change implementation procedure – contains principles, how to change a scope of a project.
- #4 Contract is not a document written by lawyers and used only by lawyers, but it is a document that describes the way how a customer and supplier will cooperate to create an IT solution and reach goals of a project. Each member of a team needs to know a contract to some extent.
- #5 Contract needs to reflect reality, i.e., how an actual work will be done during a project. If contract does not reflect a reality, then reality changes to reflect what’s written in a contract, not vice versa. Changes in a contract can be made at any time during a project – there is no need to spend too much time before the project to have a perfect contract.
- #6 Each contract motivates people act in one or other way. Good contract motivates people to cooperate in order to reach project goals.
- #7 Has there been a lot of changes since agile was started to be used in software development projects? Not so much.
- #9 If there is no clearly described outcome, then it will not be possible to demonstrate solution at the end of each sprint.
- #11 It is important to have the LEAST possible scope and use it for learning. Since agile has built-in option of self-improvement, both a customer and a supplier will be more informed and able to build better IT solution. It is also important to reach a level where a scope brings added value, because then a customer will be able to use it for a business and feel safe about an investment.
- #12 In order to be able to replace user stories and prioritize them there has to be an estimate for each user story.
- #14 If you are not able to explain your payment term in 60 seconds, there is a great probability that a customer will not accept them. There is no link between software development approach and payment terms – agile does not mean time/material. The most often used are fixed price contract, where fixed price is number of complexity points multiplied by a price of a complexity point.
- #16 Focus of this section has shifted from infrastructure to participation in a project. It is very important that a customer understands software development approach and requirements towards involvement in a project.
- #18 Although it would be nice to start programming solution immediately, there is usually a need to spend some time on doing formal things like getting access to environments, setting up infrastructure etc.
- #19 Although system testing is done during each sprint, there is a need to test a whole solution.
- #21 Usually there is no need of having separate governance procedure, since there are frequent meetings with a customer as part of agile software development approach.
- #23 Delivery and acceptance procedure has shortened, because software has to be potentially shippable at the end of each iteration. Documents are accepted he same way as before.
- #27 User stories can be replaced or they can be eliminated at all.
- #29 Support and maintenance of a solution starts as soon as some part of functionality is given to the end users. This should not be forgotten.