An earlier post described how the Agile philosophy implicitly divides software development into two types of work – user stories and building blocks. In addition, the post delved into how to distinguish between the two types of work. Here, I point out another seminal difference between user stories and building blocks.
How much is done?
During the course of a project, a critical question comes up again and again. Business stakeholders, and managers, keep asking, how much is done? What exactly is completed? What remains?
What answer do you think is most useful for them? Investigating that question reveals a defining difference between user stories and building blocks.
Status by User Story
This is a list of features that we must build. Clearly these are user stories.
As a customer service rep, I want to be able to generate an auto insurance quote.
As a customer service rep, I want to be able to email, fax, and mail a paper copy, to the customer.
As a customer service rep, I want to order a customer’s credit report.
As a customer service manager, I want to see all enrollments that are in process at this moment.
When a business stakeholder wants to know what is completed and what remains, we can simply point her to this list of business features. Is an item production ready? Is there a metaphorical green check mark against the item?
This list of work represents the value that business users are looking for, in the system we are building. Hence, the list of user stories communicates status that is immediately relevant to business, in an unambiguous, even visceral manner.
Status by Building Block
Now consider this list of work.
Build the data acces layer of the enrollment sub-system.
Implement the business logic of enrollment as production rules.
Build a REST service wrapper around the Enrollment API.
Build a web based UI for managing enrollments. This is meant for internal processors and customer service reps. This UI will sit directly on top of the business layer.
Build a mobile app for use by customers to manage their enrollments. This will talk to the REST web service.
If you tell business users, you have completed the data access layer, and business layer, does that tell them anything about what they really care about, the business features that we are building? It does not. Business stakeholders really have to wait till all of the above tasks are done before they can begin to evaluate what shape, and how much of the business features, and in what shape they have been delivered. Until then all is uncertain.
Out of this uncertainty is born magic status measurements like 35% done, 60% done, etc. These numbers convey little information that is useful for business stakeholders. Confidence in such status’ are low and always feel pathetically forced.
Thus
You can differentiate between a user story and a building block by what information they convey when we complete them. Completion of a user story unambiguously tells business what features are done, and what remain. Completing a building block leaves those questions unanswered.