Isolating and Prioritising Features
Another aspect of feedback this week was to consider looking into the methods for Agile development, and specifically how features can be prioritised based on User Stories. This isn’t something I know much about, so I’ve looked into both Agile Development and the many methods for prioritising development.
Agile development is about:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
One of the key ideas in Agile development is changing requirements and needs and responding on short time scales. It is also about continually developing and improving software.
Most versions of agile development have a prioritisation phase that delineates which features or aspects of development will be included, and then a development phase, in which developers commit to developing the prioritised features. This allows for a constant evolving and changing product.
One such method is the Scrum method, where teams have a prior meeting to determine priorities, then follow this with a Development Sprint. Another method is Feature Driven Development, which begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. The features are small, “useful in the eyes of the client” results. Unlike other agile methods, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.
A third method, Dynamic Systems Development, operates as follows:
Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:
M – Must have requirements
S – Should have if at all possible
C – Could have but not critical
W – Won’t have this time, but potentially later
All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.
I’ve come across a number of techniques for prioritising development, and Berander and Andrews (2005) offer the best summary for the range of techniques, their uses and benefits/ drawbacks. A summary of their paper follows:
When prioritising, it’s important to understand what factors you are using to generate priorities There are six main areas to consider: Importance, penalty, cost, time, risk and volatility
1. Analytical Hierarchy Process (AHP)
AHP is conducted by comparing all possible pairs of hierarchically classified requirements, in order to determine which has higher priority, and to what extent (usually on a scale from one to nine where one represents equal importance and nine represents absolutely more important).
2. Cumulative Voting, the 100-Dollar Test
The 100-dollar test is a very straightforward prioritization technique where the
stakeholders are given 100 imaginary units (money, hours, etc.) to distribute between the requirements. The result of the prioritization is presented on a ratio
3. Numerical Assignment (Grouping)
Numerical assignment is the most common prioritization technique. The approach is based
on grouping requirements into different priority groups (e.g. critical, standard, optional).
As in numerical assignment, ranking is based on an ordinal scale but the requirements are ranked without ties in rank. This means that the most important requirement is ranked 1 and the least important is ranked n (for n requirements).
5. Top-Ten Requirements
In the top-ten requirements approach, the stakeholders pick their top-ten requirements (from a larger set) without assigning an internal order between the requirements. This makes the approach especially suitable for multiple stakeholders of equal importance.
The following table outlines the scale, granularity and sophistication of each technique:
If we are to use an Agile approach, using a simplified version of AHP might be a good strategy for us.
Stuart (2008) uses an adapted model, which produces prioritised requirements by a 2×2 scale as shown below: