A feature that spends three weeks unseen can accumulate bugs and changes before anyone tests it. Smaller increments make it easier to get a response while there is still time to adjust. Feedback is information from use, evaluation, or discussion that guides the next change. section 1.2
Ship something useful before trying to make it perfect. Once people can use a product, their responses reveal what they want, like, and dislike. Feedback may come from one person with a vision, pilot users, investors, or the public. Delivery puts a product in someone’s hands; deployment also makes it run as a service. section 4.1
A demo sized for feedback
A Hello API plan targets a simple response, unit tests, onboarding documentation, and a live demo in one day. Translation and storage wait for a later milestone. The first increment gives others something concrete to respond to without requiring the whole service to be finished. section 2.0
Listing 2.1 README.md
# Hello API ## Release Milestones ### V0 (1 day) - [ ] Onboarding Documentation - [ ] Simple API response (hello world!) - [ ] Unit tests - [ ] Running somewhere other than the dev machine ### V1 (7 days) - [ ] Create translation endpoint - [ ] Store translations in short-term storage - [ ] Call existing service for translation - [ ] Move towards long-term storage
The README checklist separates a one-day release from a seven-day release, making the size of each planned increment visible. section 2.0
Feedback also improves the way a team works. Ask questions in code review, learn from comments without making them personal, and discuss changes to the review process with teammates. Revise the delivery pipeline as well as the product: neither needs to be perfect before the first release. section 5.1.4 section 4.1
