Standish reports that 64% of software functionality is never or rarely used. By eliminating wasted functionality we can spend 64% more time and money on functionality that adds value and creates ROI. Why waste money and time on functionality that will never be used?
Agile provides a way to eliminate wasted functionality by the use of User Stories and Product Backlog
Software projects often times involve requirements that are roughly defined; we rarely get the opportunity to have fully defined requirements at project start-up. Requirements normally start out at a high level and become clearer, as you move through the project. Why waste time developing coding and design documentation before the requirements become clear? Often information is created so early in the process that it becomes inaccurate and obsolete, even before the functionality is delivered. Why waste time developing documentation for requirements that will change or may never even get implemented?
Agile focuses on the just in time concept of refining and documenting requirement details, as the information is needed. This is done through the simple use of User Stories.
Project requirements are created as User Stories, story cards that describe the expected outcome from the deliverable from Stakeholder/Product Owners point of view. User Stories are used to defined requirement functionality at a level that the Project Owner can describe and understand. Project Owners are directly involved with the creation of the User Stories and in many cases become the owners of the Stories.
Each User Story describes only one function. It should describe the role, the desired function, the reason for the function and the acceptance criteria for that function.
Role: External Customer
Function: View account information
Reason: External Customer is interested in knowing what they have ordered and payment balances
Acceptance: External Customer will be able to view account activity and transactions, both history and current.
We then estimate each story using a points system. Each story is estimated in points, given the expected effort, complexity and clarity. The points will be used later to measure the velocity (productivity levels) of the team.
The User Story needs to be brief taking only a few minutes to define. It is recommended that each be written out on a 3×5 card to consciously enforce the idea of smallness. User stories reduce waste by eliminating wasted hours spent on elaborate documentation that will never be read by the project team.
We focus on the high-priority, well formed requirements leaving the less formed requirements for future iterations where they will become more defined or eliminated. This reduces time wasted on ill formed requirements that have no described value or acceptance criteria.
These stories are then prioritized and placed on the Product Backlog by the Product Owner. The prioritization of the User Stories becomes the iteration plan for the next release.
User Stories are refined and redefined as they more through the iteration process. Stay tuned to find out about how to manage User Stories using the Product Backlog.
Are your teams using Scrum?
Are your teams using User Stories?
How would User Stories help define better requirements?