Table of Contents
Ideally, a feature should adhere to the following criteria
- It should provide business value.
- It should be estimable – it must have enough definition for the development team to provide an estimate of the work involved in implementing it.
- It should be small enough to fit within an iteration – therefore, if it is too big, it should be broken down further.
- It should be testable – you should understand what automated or manual test a feature should pass in order to be acceptable to the customer.
The different methodologies use different terminology to refer to features. It is up to the team to decide which methodology or terminology to use. Extreme programming (XP) uses the terms “user stories” or “stories” to represent features; scrum uses “product backlog” to describe a feature list; feature-driven development uses “feature”; and DSDM uses “requirement.” Similarly, there are various lightweight versions of the unified process, or agile UP, that use “requirement” and/or “use case” to define incrementally deliverable functionality. Ultimately, the goal is the same – to deliver business value regularly in small increments, and sooner rather than later.
Methodology differences
Scrum calls a feature a backlog item, which tends to be larger grained and can also include non-feature items such as “set up production hardware”, or “research xyz options.”
XP calls a feature a story, which lends itself to a particularly helpful approach to defining functionality.
DSDM calls a feature a requirement, which can also include more than just system features.
Agile UP practitioners use requirements and use cases to define features.
Feature breakdown structure (FBS)
During detailed planning, agile development favors a feature breakdown structure (FBS) approach instead of the work breakdown structure (WBS) used in waterfall development approaches. Feature breakdown structures are advantageous for a few reasons:
- They allow communication between the customer and the development team in terms both can understand.
- They allow the customer to prioritize the team’s work based on business value.
- They allow tracking of work against the actual business value produced.
It is acceptable to start out with features that are large and then break them out into smaller features over time. This allows the customer to keep from diving in to too much detail until that detail is needed to help facilitate actual design and delivery.
Building an initial feature list
Before release planning and iteration planning, the team needs to quickly draw up a list of as many potential features for the system as they can. There is typically a single person responsible for collecting features (e.g. a product manager, a customer, a program manager, business analyst, or some other customer proxy), but feature requests can come from many sources. Users, customers, sales, marketing, RFP’s, development team members, management, competitors, and government regulations can all be sources of features. The team’s central feature list should have some controls to prevent duplicate items, impossible features, and overly vague requests. The team should be encouraged, however, to enter new features as they identify them, so that they can be folded into the prioritization and planning process.
An initial feature list can be a rough sketch, a superset, to be used as input for planning the release and first iteration. It represents the current potential of what the system could become, perhaps over several releases. You need not wait until all features are defined before getting started delivering software. And you need not adhere senselessly to the original list, original descriptions, or original priorities. One of the main points of agile development is that this list (like everything else) evolves, iteration by iteration.
Let’s pretend that a rough feature list is completed, a release plan and iteration plan are drawn up, and the first iteration is completed, before a couple of critical features are identified. These features simply get folded into the evolving release plan and a later iteration, and get delivered as soon as possible. But meanwhile, time is not wasted. The team starts delivering value as soon as possible, and creates the infrastructure to allow the project to adapt over time to new priorities, information, and business dynamics.
Feature list
When drawing up a feature list, features are initially described in a short paragraph, typically 2-4 sentences. This description represents a high-level summary of the feature, a placeholder for preliminary understanding and a basis for future communication. It’s rather like a headline for an article that will be written later. The goal is to spend just enough time describing the feature to have a reasonable understanding of relative size, complexity, and priority compared to all other features. A few more details will emerge during iteration planning. But the precise, concrete understanding of the feature is allowed to emerge during the iteration, as customers and developers discuss it enough to implement it, or (in some methodologies) to create automated acceptance tests that specify it deterministically.
Helpful references
User stories
User Stories Applied: For Agile Software Development by Mike Cohn
Webinar
How to Execute PI Planning with Digital.ai Agility
Organizing features
Managing a single long feature list can be difficult. It is very helpful to organize features by specifying categories, higher level functional groupings, business value or priority, and risk. Filtering and sorting by these various attributes can help break down a very large feature list into manageable chunks.
The entire list of features should be ranked in a single continuous sequence to provide the project team so that everyone can easily see which features are the most valuable. If a project starts out with 100 features on the list, it is not uncommon for 50 of those features to fall into a “high” priority category. A single sequential ranking of the features helps identify those that are the “highest of the high”, and thus should be completed first in order to maximize delivered value.
Accounting for risk
Additional consideration may be taken for the risk associated with certain features. Some features will involve designs, architectures, frameworks, or algorithms that are new to the team, or are otherwise risky. Even if such features do not deliver the highest business value, it often makes sense to bump their priority up enough to tackle them in early iterations. If a high-risk feature is addressed early in the project, and for some reason proves unworkable, the team still has time to react and work around it. This minimizes the overall risk to the project. It is up to the development team to work closely with the customer to help identify these types of issues, risks, and dependencies. It is ultimately up to the customer to prioritize features, but this critical process should not occur in a vacuum. The best teams work together to both deliver value and reduce risk throughout the life of a project.
Estimating features
After identifying features, the customer often works with key development stakeholders to define feature estimates. Feature estimates are meant to be preliminary high-level estimates that are used to drive release planning and iteration planning. The stakeholders involved in estimating may include architects, tech leads, developers, testers, writers, and managers. Many organizations have set up processes where groups work together to quickly provide initial estimates. This step can be helpful in initially determining whether the feature should be broken down further.
When initially estimating features, the goal is to quickly converge on a reasonable high-level estimate. Instead of focusing on whether a feature will require exactly 17.5 idea hours (or Gummi Bears, or NUTs, or whatever unit is being used; see below), the goal is to get reasonably close in a fraction of the time. If it takes two minutes to agree that the feature will take two to three ideal days to implement vs. 30 minutes to establish a precise 17.5 idea hour estimate, the former approach is preferred. To establish a single estimate when opinions in the group vary, teams can either take an average, develop a reasonable approximation, always use the best case scenario, or potentially use a calculation involving best case, worst case, and expected estimate if more complexity is appropriate. In any case, the discussions about differing estimates will often yield useful knowledge.
This process of defining and estimating features can initially seem difficult, and when teams first implement it, they may require several meetings to get comfortable with a process that works well for them. Over time, it becomes easier to break down features into units of work that can be delivered within a single iteration. Teams get very good at what they practice and agile development allows teams to practice estimation every release and iteration.
Estimation units
Estimates by their very nature are inaccurate, and developers have historically had difficulty producing useful estimates of all of the time required to complete a development task. Estimates of actual programming time are often inaccurate (especially if they are not rigorously compared to actual numbers). But non-programming time is even more difficult to nail down. What do you say if someone asks you how long it takes to drive across town? You use a relative measure. “An hour during non rush-hour, in good weather, if there is no construction, otherwise maybe 2 hours,” etc. These external factors are impossible to control and difficult to predict. In addition to developing code, programmers spend time testing, writing documentation, designing, participating in meetings and reviews, doing email, and so on. Compared to programming work, non-programming work is difficult to predict or control. It can vary according to your industry, your organization, the time of year, and any manner of changing external pressures on the organization.
Some teams ask programmers to include each non-programming activity in their estimates. But as we’ve said, this is not easy to do. For a given agile project, long before the team has an accurate measurement of time they spend doing non-programming stuff, they can know the relative work required to get different features done, and can plan accordingly. That’s why it is more typical of agile teams to focus their estimating on what can be most straightforwardly estimated and measured: actual programming. They focus on how much work each feature and each technical task will take, compared to other features and technical tasks. They allow the amount of time consumed by that non-programming stuff to become clear as actual velocity emerges after a few iterations. There are two main estimating units agile teams use to concentrate the focus on programming in this way:
- Work units
- Ideal time
Work units
A work unit is a relative measure that we hope cannot possibly be confused with actual time. Some such units:
- Points
- Gummi Bears
- Foot-Pounds
- NUTs (Nebulous Units of Time)
These represent the relative amount of work required to implement a feature (or task), compared to other features (or tasks). Only once the team has settled into a consistent velocity, usually over a few iterations, can they begin to map these work units to units of actual time. That is exactly the point of velocity: to describe how much work the team can do per unit of actual time.
Once the team or organization has agreed on an estimating unit, they should agree to make an effort to implement it consistently and stick to its original definition. Especially in the project’s early iterations, everyone should resist the urge to try to map these units to time units with any exact precision.
Ideal time
Like work units, ideal time excludes non-programming time. When a team uses ideal time for estimating, they are referring explicitly to only the programmer time required to get a feature or task done, compared to other features or tasks. Again, during the first few iterations, estimate history accumulates, a real velocity emerges, and ideal time can be mapped to real, elapsed time.
Many teams using ideal time have found that their ultimate effort exceeds initial programmer estimates by 1-2x, and that this stabilizes, within an acceptable range, over a few iterations. On a task by task basis the ratio will vary, but over an entire iteration, the ratios that teams develop have proven to remain pretty consistent. For a given team, a known historical ratio of ideal time to real time can be especially valuable in planning releases. A team may quickly look at the required functionality and provide a high level estimate of 200 ideal days. If the team’s historical ratio of ideal to real is about 2.5, the team may feel fairly confident in submitting an estimate of 500 project days. In fixed-bid scenarios, this kind of estimate can be reliable.
Relative estimation
Many agile teams use the practice of relative estimation for features. Instead of estimating features across a spectrum of unit lengths, they select a few (three to five) relative estimation categories, or buckets, and estimate all features in terms of these categories.
Feature vs. task planning
While the emphasis at this initial stage of planning is on speed and on the relative work per feature, at some point features must be broken down to their respective tasks and estimated more precisely. This happens during release planning and iteration planning. In general, feature estimates and task estimates serve different purposes:
- Feature estimates help drive scheduling across releases and iterations.
- Task estimates help drive resource loading within an iteration.
Because they serve different purposes, a feature’s estimate need not align precisely with the sum of its task estimates. Over a range of features, however, there should be at least a rough correlation between feature estimates and the sum of the task estimates for the features.
FAQs
How big is a feature?
This can vary to a large extent based on the development work your team is doing. A general rule of thumb is that a feature should be small enough to be completed within an iteration and big enough to warrant scheduling. You wouldn’t, for example, want to schedule nothing but one-hour features for a team of ten working on a one-month sprint. That’s way too many items to schedule and track. If there are specific feature changes that are that small, it’s often best to group those smaller changes up into one larger item for scheduling purposes. Make each one hour of effort a task under that feature.
Are bug fixes features?
They can be. Scrum, for example, teaches that all work the team needs to accomplish should be on the backlog list. Common methods for handling bugs include 1) creating a feature item for each bug, 2) creating a feature item called ‘fix bugs’ within each iteration and detailing the list or types of bugs to be fixed, or 3) handling bugs separately and not tracking time against them. The number and size of bugs your team expects to encounter should be a large factor in determining which method you choose.
Why estimate features?
Feature estimates help drive the ranking and scheduling that happen in release planning and iteration planning. To know how much work to schedule within a given period, you must have an estimate of how big each piece of work is. Also see agile velocity. If two features are of equal business value but one is half the size of the other, the team will be more efficient if it works on the first feature so it should be ranked higher than the second.
Should we update feature estimates if the task estimates don’t add up?
No, feature estimates drive scheduling. Task estimates drive resource allocations. While there should be a correlation between the values, they do not need to align precisely.
