Agile Planning: Always Plan for a Product, Not a Project!
Agile Planning: Always Plan for a Product, Not a Project!
Planning and estimation should focus more on developing a product that provides value to the customer rather than on completing the project and proceeding to the next.
Join the DZone community and get the full member experience.Join For Free
Today in organizations, we plan and estimate to make effective decisions that help us stay competitive. We engage in this activity to get answers for simple questions like:
- What needs to be built?
- When can we complete?
- How much will this cost?
- Who needs to do it?
In traditional software delivery, we have been planning and estimating by following a sequential plan-driven approach. As these projects are short-lived once completed, there is no long-term connection between the product and the teams who built it. Also, more of the unfinished work and technical debt is left behind.
But in Agile, we build Product teams and not project teams, the approach is progressive, and we keep improving and are able to deliver value quickly.
In Agile, we have Tribes and Guilds, which are dedicated teams and are responsible for long-term ownership of the product or feature. These teams focus on how much shared understanding is established within the teams of what needs to be developed and how they are going to develop it.
Below are the key pointers I think are important when we estimate and plan for Agile projects:
While we start planning, any organization should consider the six levels of the planning onion, a concept introduced by Mike Cohn. The Strategy is the outermost layer followed by Portfolio, Product, Release, Iteration, and daily segments as the core is approached.
The certainty of undertaking activities keeps increasing as the onion is peeled. So, as more details are uncovered, frequency and number of people keep increasing.
Most Agile teams are concerned with the three innermost levels of Release, Iteration, and Day as these mitigate the risk of how much we need to spend, what features need to be built, and what needs to be adjusted to achieve the product goal, which is based on customer needs.
Portfolio management is a collaborative effort between different teams of the organization, which focuses on all aspects including Finance/Procurement, PMO, Enterprise architecture, Legal, Security, Compliance, and infrastructure teams.
Instead of having disconnected teams at the program or portfolio level, we can create dedicated product teams known as Tribes and Guilds, which are responsible for the long-term ownership of the product.
Tribes are cross-functional teams that take care of end-end delivery of the product, and guilds are groups of people who share similar skillsets and interests.
These teams work with the aim of delivering value quickly and can reduce the variance (early error detection). They will be able to align with the flow of work and can plan on a regular basis based on customers' needs.
It might be challenging for traditional organizations to change from the existing organizational structure to work in customer-based feature teams, but it is possible; for example, instead of traditional business units, we can build customer journey teams, where business, technology, finance, legal, and marketing work on a customer journey or a product.
You may also like: Capacity Planning and the Project Portfolio
Agile product funding
Traditionally for IT, work budgeting is done where funding is released for one or more projects. But in Agile product funding, small cross-functional teams are assigned to workstreams that have a continuous flow model of funding. The four decisions that can be made are:
- Seed – Funding is given for about three sprints for the team to develop a prototype or MVP; subsequent decisions are made based on the outcome.
- Fund – funding for two sprints of work on the feature, to maintain and extend it
- Retire – If a product owner feels it is no longer worth adding new features to a product or capability, but it is worth keeping around, they can choose to retire it, meaning it will be switched to maintenance with 10-20 percent of funding
- Kill – final decision to shut a product down; no more funding
Senior product owners and other stakeholders should work hand in hand with all other product owners in their portfolio to continually review their products and make the decision to seed, fund, retire or kill the products.
Once the dedicated teams are formed, a portfolio backlog is created, which links the portfolio vision to the strategy, creating small investment increments that can be quickly executed to bring value to the customers.
Then the portfolio backlog needs to be prioritized based on business value. For example, we can assign to different buckets based on whether it will save money, improve customer satisfaction, generate new markets, etc. So, within the individual buckets, T-shirt sizes can be used to estimate, and the high, medium, and low priority items can be identified.
The high-level items from the portfolio backlog are in the form of a large piece of work. This is broken down to task level before proceeding with development. Below is an example of the decomposition:
Epics can be estimated using T-shirt sizes of S, M, L depending on how many sprints it will need to be completed; the maximum size is one month.
Features normally fit into a release and are estimated in weeks.
User Stories should be broken down until it comes to the stage that it can be complete within one to three days.
Tasks should be planned in hours and need to be kept below eight hours for efficiency.
You may also like: Requirements (Epic, Feature, User Story), Task Size, and Estimation in Agile/Scrum
Other key considerations on estimation
- Agile estimation is done by evaluating the amount, complexity, risk, duration, and business value. There are many agile estimation techniques that are in practice, which include T-shirt sizing, Planning Poker, The Bucket System, Fist to Five, Dot voting, Affinity mapping, etc.
- Velocity is the amount of work done by the team in a given time, and in Agile we sum up the story points that were completed in that sprint to determine the velocity. This is a kind of measure of the productivity of the team; it depends on various factors, but it best works with stable and experienced teams. So, while working with new teams, the product owners and scrum masters should be liberal and let the team stabilize.
- Relative Estimation is a kind of estimation not by units of time but how items are like each other in terms of complexity. Instead of estimating each user story separately, we estimate by comparing or grouping items of similar difficulty. For example, feature B might be "twice as complex" as feature A, which you have already completed. So, if feature A took two weeks, we can guess that feature B would take four weeks to complete.
- The No Estimation movement approaches the minimization of risk in a different way. Instead of asking how long a product will take to be implemented or how much it will cost, it asks what kind of software is possible within a certain time period or amount of money. This concentrates on the Agile Value of delivering value as early as possible and keeps re-evaluating the direction of where we are heading too frequently.
Monitoring the health of Agile projects
The health of Agile Projects should also be monitored at the portfolio level to ensure clarity on what constitutes Red-Yellow-Green in an Agile context. This will help organizations that are adopting Agile to anticipate this change and incorporate this new set of metrics in their portfolio management reporting. I would recommend the set of Traditional vs. Agile metrics, as highlighted in Deloitte Agile Project Portfolio Management (PPM).
My experience with Agile Estimation and Planning is for product development at a startup. As the team was new to Agile product development and we were working on only one product, it was difficult to estimate because the outcome was uncertain.
So, while working on the MVP, we had been doing “No Estimation." We knew the time frame and the budget we had, so we worked to identify what features of the product could be completed within these constraints. Once the MVP was completed and the development became progressive, I introduced the Planning Poker method of estimation. This was beneficial, even while working with distributed teams.
In summary, in order to succeed and provide value to both the business and our customers, the teams developing products should work by always remembering some key goals, including:
- Accuracy over precision
- Stability and Predictability
- Rapid Risk Reduction
- Fast Feedback
- Easy to change direction
- Respect People
Also, planning and estimation should progress from the top down and focus more on developing a product that provides value to the customer rather than on completing the project and proceeding to the next.
For estimation, we should try to put in minimum effort to estimate and get the job done. Estimates are mainly needed for prioritization of product backlog to identify meaningful iterations that will satisfy the customer and bring value to the business.
Apart from this, if we concentrate on improving accuracy, as Mike Cohn (Agile Estimating and Planning) highlights, we might end up with the law of diminishing returns:
Even though we spend twice as much time planning the duration of an activity, our estimate is not going to be twice as precise.
Opinions expressed by DZone contributors are their own.