This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first two parts of this series here:
Depending on which statistic you believe, many researchers in the field of software development agree that the majority of projects that fail to make it to market are those with insufficiently detailed requirements. Though I agree completely with this, many companies also fail to avoid an even more troublesome, but often overlooked issue – that of building either too many or the wrong features. Traditional waterfall based development processes spend a large amount of time creating requirement specifications and detailed design documents before any code is written. In the time between the start of a project and when coding begins, those responsible for determining the functionality of features often understand the requirements better than they did at the beginning of the project. This results in a last minute rush to cram in these requirements after the design has been done, which results in an impact on the design for which time is usually not given to developers to adequately account for them. On top of all of this, the needs of the customer (whether internal or external) may have changed or the market against which features are targeted may have shifted focus that now requires a different priority in order to remain in step with the customer or client’s needs.
These problems which I find especially prevalent in large projects with many features, are a big reason why the backlog concept for agile projects is so effective. A backlog is essentially a queue in which features are placed and then re-ordered that drives the software development team’s activities. To kickoff a new project, the visionaries of the project and those most in tune with the customer’s needs come up with an initial set of features. The goal here is not to design anything in detail, but to try to break functionality into logical features that could be stated to the customer as well as software developers (you could read these on a list of “things it can do” about your product or project in a brochure). It will be a challenge when starting out to determine what is too granular to be a feature versus too broad. If building a dashboard application of some sort for example, if all we are building are the widgets that go on the dashboard themselves, each feature of the dashboard could be a single widget. If building the framework of the dashboard itself (managing which widgets are on the dashboard, and where they are located for example), this would be another feature. Too broad of a feature would probably be “dashboard page” if this includes the dashboard and widgets together. Don’t worry however if you have some features defined too broadly at first – the process provides a means to divide up the features easily into smaller features as the project progresses.
Below is an example of a backlog created by a fictional CEO, two field market analysts, a customer representative, and a product manager during some initial meetings or via collaboration on a document. At a smaller company this may be the marketing rep and the product manager only. In a consulting engagement it may be the client project sponsor, consultant, and possibly an internal end user. It’s not important for this topic to dictate what tool is used to come up with this list or how it is stored. The important thing is to get the right people together make this initial list. If anyone is far removed from the customer, it may make sense to have them review the resulting initial list instead of participating in its creation. It is crucial that those involved do not concern themselves with time to market, cost to develop, or priority at all during step. Prioritization will be done later, this is strictly a brainstorming activity.
Here we’ve got a backlog with CRUD (create, read, update, delete) features around a few objects; namely recipes, ingredients, and meals. We’ve also got the concept of a dashboard, with a couple of widgets, and a search. It’s a good idea at this point to circulate the list to the original attendees of the meeting and let it stew for a while. Even though it’s important not to go into more detail at this phase, it is very important to establish high level scope. Identifying the major pieces up front makes planning much easier.
Once the backlog has been tossed around in the minds of the attendees for a while, and any new items have been added to it, it’s time to have our initial prioritization of the backlog. This should be done in a group, as it’s easier to get out reasons for prioritization in a group and avoids having to merge the reprioritized lists. Below is the reprioritized list. The features that are most important are at the top of the list, with those that are less important at the bottom. On a real project, this list may be over 50 items long. We’ll refer to this process as Business Backlog Prioritization.
You’ll note that the planners of the vision of the project determined that the dashboard features were most important to them. Often the most visible or sexy features will be determined as most important at this point. In a real project, the top 10-20 features coming from the visionaries help the development team to see what is most important to the business when they perform their own prioritization.
Now the development manager or team lead should meet with whoever else from their team makes sense to review the initial backlog. This could be the entire development team, or just an architect depending on time constraints and confidence in resources. We’ll call this the Development Backlog Prioritization. The goal of this prioritization and review is twofold. First, the team should try to identify any features that will obviously take longer than a sprint, and break them up into smaller features. A sprint is a fixed time period during which development of a subset of the features on the backlog are implemented, I will talk much more about them in future posts. Each development team determines what the length of their sprints should be, typically this can be anywhere from a week to 30 days. The second goal of this prioritization is to determine how realistic implementing the top items on the list are based on whether it is possible to identify any dependencies of those features further down the list that should be bumped up.
Upon looking at the backlog, the developers determine that implementing the dashboard and accompanying widgets without authentication will be difficult since much of the code tied to laying out widgets on the screen requires identifying the currently logged in user. They also feel that implementing the recipes and ingredients features first will make it possible to create widgets that pull real data. It is in this meeting as well, or a set of meetings, where the development team may be asked to create WAGs (wild-ass-guesses) for all of the features on the backlog to get a vague feel for the overall cost of the project. I’ll reserve further discussion of WAGs of the backlog for a future post on planning. Anyway, they reprioritize the list again and arrive at this backlog:
At this point the backlog is presented back to the visionaries, and they look for ways to still get the features they want earlier, hopefully understanding the technical constraints as explained by the development team representative (software development manager, team lead etc.). Finally, a compromise is reached. User authentication will be implemented but without adding and editing users initially, listing of ingredients will be implemented but without adding, editing, and deleting, and the dashboard will then be created with the initial ingredients widget. The Approved Backlog Pending Assignment is below:
At this point the software development manager or development lead meets with the team. Each developer available selects a feature from the top items in the backlog that is either most interesting to them (a challenge) or leverages a specific skill they may be advanced in until everyone on the team has been assigned a single feature. In this case, our fictional team has 4 developers, so the first four features are scheduled for implementation in sprint #1. The remaining backlog, after the features for sprint 1 have been assigned, looks like this:
At this point the visionaries are free to add, remove, and reprioritize items in the backlog until sprint #1 is complete. Prior to starting sprint #2, the visionaries must finalize their priorities and collaborate once again with the development team as described in Business Initial Backlog Prioritization. It’s important to note that a backlog should not be looked at as a list to complete. It may have items on it for the entire life of your company or product. The backlog is simply a queue that steers the direction of the project and allows development to respond with agility to shifts in the marketplace, initially missed dependencies, or changed needs of the customer. It also becomes a vital brainstorming and planning tool for capturing future ideas before they can be completely designed.
Future posts will discuss how the development team goes about analyzing, tracking, and estimating the features assigned within a sprint. The important takeaway here is that visionaries may not change the direction of the development team’s current activities until those features are complete. Using a backlog gives those responsible for steering the ship regular intervals at which to control the direction of progress, while at the same time encouraging collaboration with developers in creating a realistic, deliverable set of tasks that can be revisited and measured at regular intervals.