In agile development we have a backlog: a list of needs that we want to fulfill in a certain order. We also try to have a cross functional small team that take care of meeting the needs without having to handover stuff that must happen to other people. In certain agile frameworks (such as Scrum) the team shouldn't even have to interact with others when meeting the need so that they are able to independently take responsibility for a couple of weeks worth of work.
That means that each work item that meets a need (is valuable) also has to be small. We also want each item to be independent of the others so that we can give our primary stakeholder (for example the Product Owner role in Scrum) the opportunity to pick and choose any of the items in the backlog to be fulfilled.
In 2003 Bill Wake suggested that these three characteristics (I for "independent", V for "valuable" and S for "small") of a good product backlog item should be combined with the characteristics negotiable (in agile, a requirement is the starting point of a conversation and not the end of a discussion), estimable (just enough so that stakeholders can decide if it is worth it), and testable (if we can't test if a need is fulfilled or not, the need was probably not expressed clearly enough). And thus the acronym INVEST (independent, negotiable, valuable, estimable, small and testable) was born.
Now, while INVEST can be an ideal (since if we manage to make all of our items on the list INVEST compliant it is really easy to increase the agility in our development) many have found it hard, if not impossible, to achieve. So what should we do then? Abandon the whole idea? No. But think a bit. And know how to work with it.
The thing is that three of the letters in the acronym has everything to do with the organization. Why isn't the items negotiable? Why can't you reach a consensus on them? There is almost always a destructive power game present when people doesn't understand why the items on the backlog isn't the last word on how to meet a need or what the need is about.
Why isn't the item estimable? Are there hidden complexities that you haven't explored yet? Don't you have sound practices around refinement so that you know what it would take? And why isn't the item testable? Haven't you had all the required conversations yet? Doesn't people know what they want? Do you let people who know how to test things step up and participate in the item generation?
The N, the E, and the T are typically things that an agile transformation address, and it goes typically very well. It isn't that hard to create an environment where we collaborate on the items, negotiates what we would like to see done, make forecasts, and thinking about their testability. The problem usually resides with the other three.
Things can be cut into small partial targets. But in many environments, they are not valuable. Due to inherited complexity in the technical environment things cannot be small and valuable at the same time. They might be able to, later on, but not now. So we might have to slice down a valuable feature into smaller pieces, starting with a primitive version of the feature and improving it over the course of a few sprints. In the same manner, features may be dependent of each other and implemented and released in a certain order within a releasable package.
It is for circumstances like these a backlog split in three levels, as Dean Leffingwell suggests, is constructed. Closest to the team are the sprintable items that they can plan for and implement. A group such of sprintables is needed to implement a feature (the second level), and packages of related features that are needed together in order to generate business value (Leffingwell calls these packages Business Epics) constitutes the third.
The three tier backlog has its place when the items cannot be small, valuable and independent at the same time. It has been criticized for introducing complexity, but the idea is not to introduce complexity but to mirror the actual complexity we actually have to deal with. Then we can start to manage the complexity and hopefully work in order to reduce it.
Related: The SMIDIGT! module about the three tier backlog: documentation-the-backlog.pdf
Inga kommentarer:
Skicka en kommentar