The Dangers of Underplanning in Your Agile Projects
Make sure that your Agile project is not overplanned, but has a stable foundation on which to build.
Join the DZone community and get the full member experience.Join For Free
Agile coaches often stress the importance of not overplanning. They talk about the dangers of planning work that is later changed or never done at all. When Agile first emerged, there was a belief that upfront planning was unnecessary. Teams were encouraged to jump right into sprints and plan as they go.
While not many teams today believe this works, there are still lots of teams that underplan. Here are some planning activities that are critical to do before your sprints start.
Create an Initial Backlog
While we don't need to plan out our efforts years in advance, we do need enough clarity on requirements to know which features to build first. Creating an initial backlog of user stories that are broken down to an appropriate size, are prioritized, and are estimated is essential to getting started. Having said that, don't expect to create a good backlog in one sitting. Iterating over your stories while going through the other planning activities below will result in a better backlog that's ready by the start of your first sprint.
Think Through Architecture
While we want to avoid costly upfront design, the creation of an overall system architecture is necessary to understand the environment your software must work within. Sometimes this work has already been done by a separate architecture team, but if a system architecture does not exist, it needs to be created. If there is one aspect of design you should consider prototyping upfront, a mockup of some initial user interface screens. Nothing helps a team understand the requirements better than a visual.
Create a Test Strategy
A test strategy is a high-level description of your testing approach. It does not include test plans or test cases, as these are created during sprints. Instead, it describes the overall testing approach so everyone knows their role in the testing process. It typically answers questions like, "What types of testing will be performed and at what interface points?" "Who is responsible for each type of testing?" "What will be the exit criteria for our testing efforts?" and, "What automation is planned, who will do it, and what tools will be used?"
Set Up Environments and Tools
The team is going to need many environments (development, integration, functional testing, etc.) and tools to perform their job. Some organizations have standard environments and tools that teams can easily access, while others will need to set up these things themselves. Regardless, make sure you test out everything you plan to use so any issues can be discussed and corrected before sprints begin.
Establish Team Norms
At least a minimum viable team should be identified during upfront planning and, ideally, involved in this planning process. Initial roles should be defined so everyone understands their focus and the team can begin the forming, storming, norming, performing process while planning. The team should discuss and agree on a definition of "done" for user stories, sprints, and releases. Ideally, a team should spend enough time together prior to the beginning of sprints that they can hit the ground running and be as productive as possible immediately.
Published at DZone with permission of Jeffery Payne, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.