Week-by-Week Tasks and Milestones


  • When to use this – when you need a project planning process for a few team members, want to avoid heavyweight processes, want to optimize for engineers and simplicity, no special tools required, plain text
  • Assumption – single engineering team, that works with other teams, PM, etc.
  • What – List of bullet points : Week-by-week tasks and milestones
  • Applying Modern Agile :
    1. Make People Awesome
      1. This is a tool for you
      2. Goal is for you to be awesome at planning and delivering projects
      3. We will take the learnings from the experience to do better job of estimation and planning for the next project
    2. Make Safety a Prerequisite
      1. This is only to be discussed within the team
      2. This is not for showing anybody outside the team
      3. It is expected that you will keep changing the list
      4. You can put it up anywhere, on your laptop, in jira or wiki, wherever
      5. The only ask is that you present the updated list to the team in every team meeting
    3. Experiment & Learn Rapidly
      1. Reduce unknowns early in the process, in the first few weeks
      2. Budget time for learning new things, such as new codebase, new library, new concepts, etc.
    4. Delivery Value Continuously
      1. Milestones should be demoable and concrete
      2. First milestone should be end-to-end, i.e. cover the breadth
      3. Subsequent milestones should be about depth in one or few areas
      4. Last few milestones should be available to PM & DS to play with
      5. Last milestone should be available as sandbox for everyone in the company to play with

Creating it

  • What it looks like
    • Week 1
      • Meetings with other engineering teams, for shared understanding of who does what, and contracts
      • Write detailed dev spec
    • Week 2
      • Task 1 name – who
      • Task 2 name – who
    • Week 3
      • Task 1 name – who
      • Task 2 name – who
      • Milestone 1 : first cut demo
    • Week 4
      • Arch review – who
      • Task 1 name – who
      • Task 2 name – who
    • Week 5
      • Task 1 name – who
      • Task 2 name – who
      • Milestone 2 : more depth
    • … (more weeks) …
    • Milestone n : dev complete
    • Week 6
      • Op review – who
      • Integration testing – who
    • Week 7
      • Sandbox deploy – who
      • Bug fixes, if any
    • Week 8
      • Beta launch – who
      • Monitoring – who
    • Week 9
      • Celebrate!
      • Feedback improvements, if any
  • Weeks need not be continuous, there can be breaks such as on-call week, etc.
  • Creation of this list comes first in every project – create while reading PRD
    • This does not mean project has started
    • Output is ballpark estimate and shared understanding of actual tasks (not details)
    • Output is list of unknowns or things that need prototyping or benchmarking or learning, etc.
  • Milestones – something demoable – Follow Modern Agile : deliver value continuously.
  • Week 1
    • Dev spec
    • Meetings with other engineering teams, for shared understanding of who does what, and contracts
  • Reduce unknowns in early weeks by experimenting
    • Build end-to-end rough cut in first milestone, demo to stakeholders
    • Every subsequent milestone, add depth
  • Add weeks, in correct sequence, for company processes like arch review, op review, deploy process, staging process, integration testing, sandbox for customer success and sales engineer, etc.
  • Parallelize, if possible, by assigning tasks in each focus area in each week to multiple people; don’t overlap
  • Discuss extensively in team meetings, esp. architecture, scalability, performance, maintainability, etc.
  • Output – all engineers in the team have clear idea of what is the work in a project, esp. PRD is clarified.
  • Ideal – engineers can work autonomously during dev phase, no surprises or delays during dev phase (exceptions should be exceptional – whether customer issues or on-call), no “rush” phases, no weekend work, with room for experimentation, easy to track progress, easy to spot if someone is stuck, easy to gauge if we underestimated effort or did not foresee something – this will be good knowledge for future projects
  • This applies to all types of projects – feature work, tech debt work, craftsmanship work, etc.
  • Manager and/or tech lead involved heavily in this phase

Using it

  • DRI (directly responsible individual) who will actually work on the project is responsible for taking this list, putting it on a wiki page / task page, sharing link with the team, updating it constantly, and quickly raise any issues that are blocking or delaying the week-by-week plan
    • Ideal – engineers can work autonomously during this phase, i.e. manager or tech lead involved lightly in this phase
    • Manager is responsible for minimizing distractions
    • Use checkboxes to indicate completed weeks
    • Add new weeks for internal delays or unforeseen tasks – mark new week title in italics
  • Weekly team meetings are discussing updates w.r.t. this plan, demoing milestones, discussing ideas and concerns.
  • Unforeseen delays are okay, add to the bullet points list between the task-weeks it happened – useful in retrospective; immediately, discuss with manager or tech lead; they will, in turn, inform stakeholders