No, don’t worry, this is not an advertorial for some investment scheme. This is about the INVEST and DEEP principles. Principles which are supposed to make working on a project easier. Reality is, I have never seen a project go by not spending time debating these same principles and how they apply to our day to day work, hence what our clients are paying for. INVEST and DEEP are two sets of principles used a lot, but should we value one over the other?
Bill Wake’s INVEST principles are all about streamlining agile team internal dynamics. The promise is that Backlog items complying to the INVEST principles can be handled by the team without reservation. Typically, an INVEST principles based Backlog has a prioritized list of Product Backlog Items ready to fill the next 2 – 3 Sprints.
Independent refers to the fact that one Product Backlog Item should be independent of another as much as possible. Dependencies between items could make planning, prioritization and estimation for a Sprint difficult. Independent does not mean small;
Negotiable refers to the fact that implementation details of the Product Backlog Item can be worked out as the team goes along. In its purest sense negotiability is just an indicator of change: any Product Backlog Item can change until put in a Sprint. Some teams take the negotiation part very serious, wanting to have a say in everything. On the other hand, it is perfectly fine for a Product Owners to point out the functional “how” with a decent level of detail. At a bare minimum, the intention of an item has to be unambiguously clear and specific;
A Product Backlog Item has to be valuable to the business stakeholder, hence, the “Why is this item important?” The stakeholder can be the customer, a team member or the team itself. Rather technical items can be valuable to the business (i.e. code maintainability). To be able to understand business value, the team actually has to have some understanding of the domain the client acts in. Not all business value can always be explained in layman's terminology.
A Product Backlog Item has to be estimable, that is, there needs to be enough unambiguous detail for team members to estimate it to allow for its planning in a given Sprint.
A Product Backlog Item has to be small. Now, “small” is very subjective and dependent on the confidence level of the team, but the idea is the team should be able to complete it easily in a given Sprint.
Last but not least, testable refers to the fact that one must be able to easily verify a Product Backlog Item is delivered as intended, hence “done”. This means the Product Backlog Item has to comply with given acceptance criteria that allow for its (easy and possible automated) testing and completion.
Almost every project now has a Product Backlog. However, much less often this Product Backlog has DEEP characteristics. Working ahead to capture and approve a lot of requirements, denies the business and team the opportunity of trial and error by discovering what is really needed. As a result, the Product Backlog just looks like a traditional requirements baseline.
Instead, a Product Backlog is intended as a “To Do” list. That is, a list containing items to detail, to implement when prioritized and to validate. The elaboration of Product Backlog Items is performed just before the Sprint, their validation only after implementation. In fact, validating a Product Backlog Item means assessing the solution meets the requirements, not whether the requirements are spelled out correctly. Hence there should be no validated or approved requirements in the Product Backlog. Now, what does Mike Cohn’s DEEP acronym stand for?
Detailed appropriately, that is, an item on the Product Backlog has the right level of detail. Practically, this mean the items lined up for implementation in the next Sprint will be smaller and the items that will not be addressed immediately (a lot) bigger. It’s unwise to include only detailed items on the Product Backlog. Product Backlog management will be harder, since change tends to result in a lot of rework. Overview is dispersed, making it harder and more time-consuming to prioritize and plan. In short, too many details on the Product Backlog are a waste of time and energy.
Each and every item on the Product Backlog has to be estimated on a relative scale. This allows for comparing items. Estimates are an important instrument since the Product Backlog serves as a planning tool. Having a prioritized and estimated Backlog and knowing a team’s velocity, one can easily indicate which items can be incorporated in which Sprint.
Typically, the Product Backlog is emergent. This means the Product Backlog continuously has to change, to reflect what is needed to achieve the wanted business value. Hence and in general, a Product Backlog is never final. The Product Owner and team change the items, their priorities and estimates continually to the latest insights. These insights change because one continuously learns more about the product, its users, the environment and technology it is supposed to be implemented in and last but not least new insights from any of the stakeholders.
Items on the Product Backlog are prioritized. The Product Backlog Item with the highest priority is at the top of the list, candidate for being implemented first. The Product Owner assigns priorities after consulting with business stakeholders, users and team members. Priority of a Product Backlog Item may be influenced by its business value, minimal marketable value, risks and dependencies. Prioritization is essential for delivering as much business value as possible. The Product Owner is responsible for maximizing the business value delivered for the budget spent (ROI).
Escaping the Safe Bubble
If we look at the principles of both INVEST and DEEP there are a lot of similarities. In the broadest sense, each of the DEEP principles can be mapped to one or more INVEST principles and vice versa. Although this may differ from team to team, the actual difference between the two sets of principles -to my experience- is in how they are applied in practice.
The INVEST principles -written down as adjectives- tend to be used in a prescribing way to ensure work on the Backlog gets done in a (very) predictable and methodical way. On the other hand, the emphasis using DEEP –spelled out as past participles- focuses on the end result (delivering business value) and everything else is subordinate to the creative process over getting there. Stereotypically, with INVEST one (continuously) has to agree on the terms before the actual work can be done, whereas with DEEP your only guidance is the incremental business value being delivered, the principles being beacons to keep you on track.
In an agile environment, professionalism is what counts, since one has a lot of freedom, but also a lot of responsibility. Depending on the client’s or even project’s appetite, available principles, rules and best practices have to be put at work in the right mix. In the end, principles should be used to make our work easier, more efficient, but foremost, to get the work done that is necessary to deliver the wanted business value.
While INVEST principles suit agile team internal dynamics by keeping the majority of the team focused on most of what is relevant, they do tend to create a safe bubble for the team to efficiently work in. This has some parallels with the odd “room without windows” developers sat in to finish their tasks in the old days. As a consequence, teams using solely INVEST principles give both the team and business stakeholders a false sense of security, responding rather formalistic to change.
DEEP principles focus on just-in-time and just-enough, opening up the agile team to a real life, changing environments and business value, incorporating discovery of new facts, but in doing so being generally less efficient in terms of time and resource management. Should we value on set of principles over another? My advice: DEEPen your INVESTment by:
1. Having a shared Product Vision, stating (initial) business goals and (known) risks. Shared in this context means shared with all stakeholders, not created by all stakeholders. This allows the agile team to get a clear picture of the problem and solution domains, serve as a lighthouse on the horizon for all stakeholders and can help to scrutinize change;
2. Incorporating DEEP in your Product Backlog makes it more action driven and change sensitive. When a customer starts a project, one has to assume a basic business value assessment has been made. The mandated Product Owner has to give direction as to (functionally) how and when to deliver this business value. Instead of having to negotiate on business value, the team should primarily negotiate on implementation.
Likewise, instead of going through the rather theoretical exercise of creating small and independent items, the team should be looking for an item size that allows for adding business value at a healthy pace, dealing with dependencies in a smart way. One should value trial and error discovery of what is really needed, adding details at the last sane moment, over fixating everything on the Backlog and measuring progress in terms of burning items. As doneness takes different forms for different Product Backlog Items, this helps keeping track of our efforts versus business value and prevents creating a false sense of security with respect to progress.
3. Keep track of business value by naming your Sprint Goals. Logical because the Sprint is the (logical) unit of change delivered. More importantly, it allows for a more coherent creation of business value and stakeholder focus, not to forget it allows for absorbing change when implementing a given Sprint. This differs from the typical team velocity approach, where the cut-off point for a Sprint is on prioritized story points rather than on coherent business value.
Increasingly, clients ask us to help solve hybrid challenges. Irrespective of the team of professionals already in place, solutions tend to affect both IT and the organization using it. Product visions written upfront evolve over time, as do businesses themselves. People change their minds and sometimes mentality. Although external to the agile team, this does have an impact on team internal dynamics. Integrating INVEST and DEEP principles give teams a competitive advantage in delivering business value over strictly adhering to each of them individually.