Software product success requires timely delivery
There are many factors that influence our ability to properly scope, schedule, and deliver software. When we propose changes in requirements we introduce risk to the schedule. We can set reasonable expectations for our stakeholders while maintaining a realistic work environment and schedule. In part 1 of this post we detail a requirements triage process that organizes requirements by complexity and allows us to set and meet expectations of delivery.
In part 1 of this article: A method of classifying requirements based upon the complexity of their implementation.
In part 2 of this article: A scheduling approach that uses variable lead times combined with our classification scheme.
- Someone plays the role of product manager, specifically gathering requirements and validating their delivery schedule with the stakeholders
- Someone plays the role of project manager, organizing the team’s activities to deliver according to the schedule.
- The team members are competent, and their estimates are realistic (i.e. we can capture and address estimation risk effectively with PERT).
- We are starting with a project that is currently scheduled properly, and on time.
- We are using an automated test process that allows us to deliver without a designated code freeze.
- We have an incremental delivery model, with multiple releases in the schedule.
Classifying requirements by complexity
We group our requirements based upon the complexity of the implementation (a simply worded requirement could have a very complex implementation). We interpret complexity by two measures, level of effort and risk. Effort represents the amount of work required to code/test/document and deploy the features required to implement the requirement. Risk represents the risk of introducing a bug or slipping the schedule for the project.
There are four buckets, each representing a level of risk and a level of effort.
- Simple implementation or minimal risk
- Easy implementation or low risk
- Hard implementation or appreciable risk
- Major implementation or high risk
Simple implementation or minimal risk
Any requirement or feature that requires fewer than 2 hrs to implement, and has no known impact on the rest of the code. Further, this is easily within the skills of the assigned developer to implement – a no brainer. The developer is able to provide a narrow PERT estimate for the work (+/- 30 minutes). For all of these categories, the time to implement is expressed in developer-hours, not calendar hours. A 2-day task could be completed (potentially) in half a day by a team of four developers.
- Help file links, release notes, collateral documentation or content updates
- Changes to data that is processed by the application
- Minor UI layout changes without behavioral changes
- Correction of spelling errors, missing labels, etc.
Easy implementation or low risk
A requirement that can take up to a day to implement, and does have some dependencies on other areas of the code. From a risk standpoint, the implementation approach is well understood, and has been done before – totally do-able. The developer is confident in a PERT estimate with no more than an hour of “worst case” buffer.
- Small and straightforward interaction changes in the UI, like changing from radio buttons to a combo-box, or duplicating menu functionality in a context menu
- Minor bug fixes – correcting errors in previous releases or builds, discovered after a release schedule has been “defined”
- Small extensions of existing functionality – adding sorting to tables, simple extensions to existing data schema, etc.
Hard implementation or appreciable risk
Requirements that can take up to a week to implement. An implementation approach that is expected to work but the team members may not have a lot of experience with it. PERT estimates may have a “worst case” buffer of up to a day (for example: best case 24 hrs, likely 32 hrs, worst case 40 hrs). If there are strong dependencies on external groups, there is also a risk factor involved.
- Significant extensions of existing functionality
- New, but straightforward functionality
- Complex user interaction changes
- Easy additional integration requirements (with external systems)
Major implementation or high risk
Requirements that take over a week to implement. There is a practical upper bound of requirements that exceed the length of the release cycle – the work supporting these requirements should be decomposed into seperate deliverables and scheduled independently. Work that requires scheduled innovation or that the current development team has never done before is high risk. External dependencies on unproven teams can also make a deliverable high risk. Work that requires inadequately tested code to be modified is also high-risk.
- Support for additional platforms (new operating system, new database, new browser)
- An overhaul of the user interface
- Significant change to existing functionality
- Complex additional system integration
Triage
Each team may need to slightly adjust the definitions of the buckets, based upon their level of risk-tolerance, their development skills, the effectiveness of the project manager (or organization) to execute and make things happen. The examples listed above are representative – if they don’t apply for a given team or project, create comparable examples, using risk and level-of-effort as guidelines.
When new or modified requirements are presented to the team, the first thing that the team should do is estimate or scope the amount of effort required to implement them in the desired release (taking into account leverage of existing and concurrent development). Determining which bucket to put the requirement in is independent of the decision to implement the requirement.
Part 2
In part 2 of this post we will talk about how to manage the scheduling of requirements that are defined in each of the buckets.
