This post is based on my answer [SE:SE:a/263596] to the Programmers StackExchange question "How to break up a programming project into tasks for other developers?" [SE:SE:q/263589].

How to break down work? So you have this big project coming up. No matter whether you're a requirements engineer, project manager, product owner, scrum master, lead developer, architect, team lead, line manager, or whatever, many of us are in a role or situation where we're confronted with the question "how do we split this?". Last but not least to also answer a bunch of other questions: "How much effort is this?" "How much time will it take?" "Can we do it?"

So here's my hit list of how to break down a programming project.

1 Basics

• Don't go alone. Try to involve your teammates as much as possible.
• Travel lightweight.
• Democracy, but not too much. Often it's not about what satisfies the biggest number of people, but what hurts the least number of people.
• Keep what (needs to be done) and how (it is done) separate.
• Learn about Scrum ("what"), XP ("how"), Kanban ("how much"), Lean ("what not"), and DevOps ("with whom").
• Lean also is about flow: For overall efficiency, flow efficiency is usually more important than individual efficiency.
• Learn about Software Craftspersonship, Clean Code, and Pragmatic Programming.
• Good architecture is about maximizing the number of decisions not taken.
• Scrum / XP / Lean / Agile is (also) about maximizing the amount of work not done. Reduce waste. YAGNI.
• The Primary Value of Software is that you can easily change it. That it does what it should do is important but that's only its Secondary Value.
• Prefer an iterative and incremental approach, use time boxes for almost everything, especially meetings, make Parkinson's Law your friend because Hofstadter's Law applies.
• Balance team structure with an understanding of Conway's Law and Tuckman Stages of Team Development.
• Programming is a quaternity, it is science, engineering, art, and craft, all at the same time. And those need to be in balance.
• Just because Scrum / XP / Lean / Kanban / DevOps / XYZ is good for someone (including me) doesn't necessarily mean that it's also good for you or suits your environment. Don't believe the hype, don't blindly follow it, understand it first.
• Feedback! (XP value) Inspect and Adapt! (Scrum Mantra)
• Avoid Duplication - Once and only Once! (XP Mantra, Lean) aka DRY aka SPOT.

2 What world work break down process

• Collect Requirements as User Stories / Job Stories into a Product Backlog.
• User (of a Story) similar to Actor (in UML) similar to Persona similar to Role.
• Refine User Stories until they meet your team's Definition of Ready based on INVeST (Scrum Ceremony: Backlog Refinement).
• Sort the Product Backlog by Business Value.
• Don't start work on a Story before it's Ready Ready (ready according to the Definition of Ready).
• Use Planning Poker to estimate the effort of Stories in Story Points. Use Triangular Comparison to ensure consistency of the estimates.
• Yesterday's Weather is the best estimate, hope the worst.
• Split Stories if they are too big.
• Improve delivery culture with a Definition of Done.
• Don't accept the implementation of a User Story before it's Done Done (done according to the Definition of Done).
• Multiple teams working on the same code base should agree on and share the same Definition of Done (especially the Coding Standards).
• Check your progress with Burndown Charts.
• Regularly check with your Stakeholders whether what the team delivers is what's really needed. (Scrum Ceremony: Sprint Review)
• Do you really need estimates? Really? #noestimates

3 Story Breakdown

• List and Describe Users / Personas / Actors / Roles (Product Owner)
• Epic ⇒ Stories (User Story or Job Story) (Product Owner)
• Story ⇒ Acceptance Criteria (Product Owner)
• Story ⇒ Subtasks (Dev Team)
• Acceptance Criteria ⇒ Acceptance Tests (Spec: Product Owner; Impl: Dev Team)
• Start with a Walking Skeleton and deploy it to production within 2 days.
• Expand the Walking Skeleton into an MVP.
• Expand the product from the MVP using SMURFS. [SMURFS]

4 How world realization

• Use OOA/D, UML, and CRC Cards, but avoid the BDUF
• Implement object-oriented, structured, and functional at the same time as much as possible, regardless of the programming language.
• OOP enhances structure, FP enhances behavior.
• Use Version Control (preferably distributed, and thus Git or Mercurial). Follow Trunk Based Development.
• Start with Acceptance Tests.
• Use BDD to shape a Test Automation Pyramid.
• Apply TDD, letting the Three Laws of TDD and the TPP drive you through the Red-Green-Refactor Cycle, with the Single-Assert-Rule (SRP for tests), 4 A's, Given-When-Then from BDD, and TCR.
• Unit Tests are tests which run fast. ― Michael Feathers
• Apply the SOLID and the Package Principles to manage Coupling and Cohesion.
• Apply the Law of Demeter / Tell, Don't Ask (aka Principle of Least Knowledge).
• Use Continuous Integration / Continuous Delivery / Continuous Deployment (DevOps). Implies Continuous (Automated) Testing. Aka Continuous All The Things.
• Use Collective Code Ownership based on agreed common Coding Standards.
• Mercilessly apply Continuous Design Improvement (fka Continuous Refactoring) to Design Patterns.
• The Source Code is the Design. Still, upfront thinking is indispensable, and nobody will object a few (few!) good clarifying UML diagrams.
• XP doesn't mean no day is architecture day, it means every day is architecture day. It's a focus on architecture, not a de-focus, and the focus is on the code.
• Keep your Technical Debt low, avoid the four design smells Fragility, Rigidity, Immobility, and Viscosity.
• Architecture is about business logic, not about persistence and delivery mechanisms.
• Architecture is a team sport — There is no I in Architecture.
• Project Code is the ATP-Trinity with priorities: 1. Automation Code, 2. Test Code, 3. Production Code
• Regularly check with your team peers whether how the team delivers can be improved. (Scrum Ceremony: Sprint Retrospective)
• Tests should be FIRST
• Pair program everything. Use advanced pair programming that combine with and amplify other methods, like Ping Pong to amplify TDD.

If all this scares you, don't worry, because it should scare you! Not as much that it keeps you from doing software, but enough to know that you have to be on your toes if you want to do a good job. Making software development projects in teams successful is not an easy task. And rarely are people trained and educated in this art. If this scares you, your intuition is working properly, listen to it. You want to be prepared. Talk to your boss, get some time and training.

5 Further Reading

5.1 Online

• Portland Pattern Repository by Ward Cunningham
• Principles of OOD by Robert "Uncle Bob" C. Martin
• The Three Laws of TDD
• Pragmatic Programmer Tips
• Trunk Based Development
• Manifesto for Agile Software Development
• Manifest for Software Craftsmanship

5.2 Books

• Clean Code by Robert C. Martin
• Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin
• The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and Dave Thomas
• Working Effectively with Legacy Code by Michael Feathers
• Refactoring: Improving the Design of Existing Code by Martin Fowler
• Refactoring to Patterns by Joshua Kerievsky
• The Ten Day MBA by Steven Silbiger (sic!)
• Domain-Driven Design by Eric Evans
• User Stories Applied by Mike Cohn
• Object-Oriented Analysis and Design with Applications by Grady Booch et al
• Design Patterns by the Gang of Four
• Test Driven Development by Kent Beck
• Extreme Programming by Kent Beck
• Effective Java by Joshua Bloch
• Structure and Interpretation of Computer Programs by Hal Abelson, Gerald Jay Sussman, and Julie Sussman

6 What matters most

All of the above only matters if it is aligned with higher goals. The higher goal is happiness. Customer happiness and team happiness.