Finding and maintaining balance is a major theme of life—between work and leisure, time alone and time with others, eating healthy food and enjoying a treat.
Software projects also involve a lot of balancing. One big facet (highlighted by conversations around Agile vs. Waterfall) is the balance between spending time to build precise plans in advance vs. starting to build real software as soon as possible and leaning on feedback to work toward the best result.
If we find the right amount of detailed up-front planning and documentation, it will support a healthy Agile software project and increase our ability to collaborate effectively, deliver working software, and respond to change.
The Agile Manifesto itself hints at this balance.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Balance. Having enough process to promote the right interactions, and good enough tools to not get in the way. Having enough documentation to give the team a good chance at building the right software. Having enough of a contract to promote collaboration. Enough of a plan to provide a path to start down and some options to exercise when changes are needed.
So what do these plans look like?
The Plans
On our projects, plans can take many different forms. A few of the most common artifacts are:
- UX Design Artifacts – personas, user stories, user interface sketches, etc.
- Product Roadmap – an outline of priorities for major features over time
- High-Fidelity Designs – detailed screen mockups annotated with descriptions of behavior, functionality, edge cases, and other considerations
- Documented Technical Approach – descriptions of the domain conceptual model, file formats, data translations, edge cases and constraints to keep in mind
- Epics – high-level descriptions of major features or groups of features with a rough total estimate to aid with planning
- Sprintable Stories in the Backlog – well-defined work that the team could pull into the next sprint and start working on
Now, let’s take a look at how to find the right balance, starting with some indications that a project may have too much or too little planning done ahead of development.
Indications of Too Little Planning
When too little planning has been done ahead of time, a project can suffer from confusion and scrambling to keep work moving forward. Here are a few specific things to keep an eye out for. If you experience these on your project, it might be a good idea to invest more time working on those plans.
- De-prioritizing even a few small stories causes a scramble to keep the team productive.
- Team members provide conflicting answers about what other features are on the horizon.
- Team members have a hard time connecting their work to the value it provides to users.
- Stakeholders are confused about when key features will be available.
- Small questions frequently cause big swings in plans.
- Delivered features miss the mark so badly that they don’t generate useful feedback.
Indications of Too Much Planning
Just as too little planning can be a problem, too much planning can have its own set of challenges. Indications of investing too much in your planning phase include:
- A pattern of significant time spent reworking designs before they can be made sprintable—assumptions and patterns have changed dramatically since designs were created
- Repeatedly spending a lot of time on detailed designs for features that don’t get built
- Stakeholders who are frustrated or nervous because they haven’t seen any working software yet—you’ve spent all your time planning and documenting
- Stakeholders who are highly invested in detailed plans and surprised/disappointed when valuable learning results in change
- Lots of time spent solving for use cases that won’t happen in practice
Balance in Practice
Balance results in plans that decrease in fidelity the further we look into the future. Near-term plans are high-fidelity: sprintable stories, detailed design comps, and prototypes.
Further out, the fidelity decreases: key user stories mapped out, how data probably fits into the system, eventually slimming down to a rough roadmap of feature areas planned. Lower fidelity artifacts are typically easier to update when plans change and frequently isolated from some types of change (e.g., visual design changes).
Balance won’t look the same or require the same amount of effort for every project. Things that affect the balance include:
- Team size – bigger teams need bigger bodies of planned work
- Complexity – more complex features need more time for planning and design up front
- Risk management – bringing more fidelity to future features can help identify risk, at the risk of future rework
The primary metric that we use to evaluate the health of a project’s plans is having four to six weeks of sprintable work in the backlog. This gives us a good amount of flexibility (enough work to create parallel tracks of work and pull alternatives forward if needed) and provides enough sight lines to the future to plan and build in the right direction.
How do you find and maintain the balance of detailed planning on your projects?