One of agile development’s core principles is to deliver working software at the end of every sprint. Teams accomplish this by defining robust user story acceptance criteria, committing to the sprint as a team, automating testing, demoing sprint results, and maturing other practices to ensure that code is complete and ready for production.
Organizations adopting devops practices, including CI/CD (continuous integration/continuous delivery) pipelines, develop the automation to push code to testing environments; the most advanced teams implement continuous deployment where they push code to production at the end of every sprint or even more frequently.
Ask some of these teams what they are delivering next month or at upcoming releases and many will struggle to answer the question. Ask how they ensure that their priorities positively impact customers and end-users and they’ll admit to limited understanding, reach, and visibility to adequately answer this question.
Then consider deeper questions:
- How often has one user story that looked easy to implement led to multiple stories executed over several sprints?
- What is the cycle time for new features, measured from the time the product owners list them in the backlog to when they are fully delivered to customers?
- Are teams reinventing the wheel, or are standards evolving as teams deliver new capabilities?
- Are teams blocked by activities such as hiring, upgrading infrastructure, training, and other activities that require lead times longer than a sprint or two to plan and execute?
- How often are operations teams caught off guard by the timing, scope, activities, or risks of an important application release?
If you don’t know the answers to these questions or if they are known issues, then your organization likely needs to do more planning.
Agile development teams have invested significantly in the technical processes and automation to enable more frequent and reliable application releases. What about steps to ensure that what is shipped delivers business value?
Why planning is hard for agile teams
I’ve spoken to many agile leaders about their planning practices and whether they invest time in developing forward-looking backlogs beyond the next sprint.
Some will say that planning multiple sprints is not agile. Their perspective is that agile enables product owners and teams to listen to customer feedback, review user behavior data generated through the application, and consider other signals to adjust priorities at the start of every sprint. Their perspective is “Why bother planning when the team will adjust priorities anyway?”
Other teams want to plan but haven’t developed the practices and collaboration to plan effectively. Some struggle to get the product owner to provide enough detail on future priorities. Others get too many priorities from their product owner. Most struggle with getting sufficiently defined requirements, making it difficult and potentially expensive to plan.
The one thing I consistently hear from groups is that they aren’t given sufficient time to plan and that they don’t have a planning process. They are overloaded with too many features, user stories, technical debt, operational improvements, and other development priorities. Planning is just not a priority.
Why businesses need forward-looking plans
Mature companies and enterprises need—and many require—forward-looking plans and roadmaps from their agile teams. Most organizations need them in order to plan other business activities tied to the application’s release. For software companies, this might include developing marketing materials, training sales teams, and informing key customers about new features. Also, more businesses today develop applications for both internal and customer needs; these organizations must also consider training employees and updating customer support functions on new capabilities.
Agile teams also must consider needs that require longer lead time. For example, when introducing new technology, operations teams will need time to install and configure it on the cloud or in the data center. If the organization needs to hire employees or onboard new people from service providers, this often requires plans that go well beyond the next sprint.
Solving the agile planning paradox
Planning with agile teams has several principles that need consideration. These five are critical:
- Organizations need a forward-looking perspective. It can be a vision statement, a strategic plan, or other communication that establishes a north star on what customers or users need and what business performance indicators are targets. Unlike a real north star, this communication also needs to be agile and updated iteratively as customer and business needs evolve.
- Teams need time to plan. Planning doesn’t come free, so if the enterprise values or requires forward-looking plans, then managers must allocate time for teams to brainstorm, review data, learn directly from customers, invest in proof of concepts, and document user stories weeks ahead of when the actual stories are prioritized.
- Teams need a defined planning process that aligns with agile principles and with the agile backlog tools in place. This planning process needs to use people’s time efficiently, with well-defined outputs and established roles and responsibilities. Organizations should also consider planning standards and determine where teams can self-organize to address the particulars of their application and technology.
- Planning should align with the primary artifacts used by agile development teams, especially the quality of requirements in user stories, steps to estimate user stories, and whether stories align with technology, data, security, user experience, and other standards. Planning should also align with operational needs to support the application in production environments.
- Planning practices need mechanisms to measure effectiveness and impact. Are teams delivering according to plan? Are they making business impact with prioritized plans? Are they using information and data captured after a release to readjust practices and priorities?
These principles can lead to a wide range of planning practices. Larger organizations may opt for SAFe’s PI Planning process where planning activities are scheduled during an innovation and planning iteration. Nimble organizations should consider continuous agile planning, where teams commit to planning activities every sprint, along with work to deliver user stories. Some organizations may also look to implement planning through agile product and portfolio management tools.
It’s easy to get lost without a plan
The strength of agile practices is that they help teams focus on short-term, well-defined deliverables. The weakness is that it’s easy for teams to get lost on the journey. Teams should review their delivery history through completed stories to evaluate their medium and longer-term performance.
Do teams say what they will deliver and deliver what they say? Do deliveries have a positive impact on customers and end-users? Are communication and feedback loops in place to help prioritize backlogs and refine requirements?
Establishing agile planning practices can help teams address the gaps.