2 min read

Microservices rules #10: Make smaller, safer, and reversible changes - part 5

Microservices rules #10: Make smaller, safer, and reversible changes - part 5
Microservices rules
Microservices rules #10: Make smaller, safer, and reversible changes - part 5

This is another article in the series about microservices rules: what good looks like, which are a set of principles and practices for using microservices effectively. The complete set of articles about microservices rules are:

  1. Practice continuous delivery/deployment
  2. Implement fast, automated deployment pipelines
  3. Apply Team Topologies
  4. Provide a great developer experience (DevEx)
  5. Use a deliberative design process
  6. Design independently deployable services
  7. Design loosely coupled services
  8. Design testable services
  9. Develop observable services
  10. Big/risky change => smaller/safer and (ideally easily) reversible changes - part 1 - incremental architecture modernization, part 2 - continuous deployment, part 3 - canary releases, part 4 - incrementally migrating users, part 5 - smaller user stories
  11. Track and improve software metrics and KPIs

This article explores yet another way to achieve Microservices Rule #10: Make smaller, safer, and reversible changes. Work items flow into a team in four main forms: features, defects, risks, and technical debt. Previous articles on Rule #10 focused on implementing and delivering work items incrementally. However, another effective approach is to reduce the size of the work item itself — specifically, implement smaller features, or in other words, define and deliver smaller user stories.

This article explores how defining and delivering smaller user stories accelerates learning and experimentation — essential ingredients for building a great product.

This post is for paying subscribers only