Instead of estimating User Stories, ask: how might we change this story so that we deliver working software tomorrow?
While delivering working software daily is good development practice - what does it mean deliver?
Can the customer accept working software daily into production, or is the working software placed in a holding bin, ready for production sometime n the future.
Does the software then age faster than the customer can put it to use, in the presence of changing requirements?
In any non-trivial environment, it is likely that the customer is actually looking for a set of Capabilities needed to run the business with, rather than a collection of individual Stories, that will someday be assembled into a set of Features, which will then enable a set of Capabilities that implement some strategy for the business needed to operate and make money according to some Plan for recovering the investment in the software.
This is another example of the myth of incremental delivery when the customer is looking for a solution, not a collection of parts that are evolving in front of their eyes. The granularity of the incremental and iterative solution must be stated before success can be achieved. This granularity comes from the Roadmap and Release Plan. See What Software development Model's Aren't Iterative and Incremental? In our domain, which uses agile for most of its software development now, Incremental Commitment Spiral Model is the starting point for working software in boundaries the customer needs.
This does not mean incremental and iterative on a daily basis not the best way to develop software, but coding, testing, verifying, validating, certifying, configuring, managing changes, securing for production and finally deploying to production are three separate steps in the delivery of the Capabilities needed to operate the business.
Imagine a story by story delivery to production of a payroll system at a high level. Here are some Capabilities of a payroll system that can be decomposed into Features and then into, Stories on a daily basis would be much lower in the hierarchy. The Capabilities are usually fixed, driven by government, GAAP, and other accounting and payroll rules. Features depend on the firm, and of course, the Stories will emerge as the users see Features being put into place. This is a notional example from experience with payroll in a commercial domain. Actual systems are more complex. See ADP, NetSuite, Jamis, Dynamics, SAP, and other services.
- Employee information - During the new hire process, companies must collect information like medical insurance and W-4 forms to determine what should be deducted from an employee’s paycheck.
- Salary Information - designate which employees are full time, part time and contractors. Classifying workers properly to avoid the government levied high penalties on companies that categorize employees incorrectly.
- Time capture - some workers are paid a salary, others are paid hourly or designated as nonexempt employees. Include timesheet information or areas where hourly and nonexempt employee hours are recorded and reviewed for accuracy. Collected time information through a computerized time clock, punch card stamp clock or paper timesheet.
- Applicable taxes and deductions - consider year-to-date annual earnings, wage levels, and tax allowances to summarize taxes. Calculate deductions made through pension plans, 401(k)s, insurance plans, union dues, and garnishments. Monitor loans and other deductions that have cap amounts and ceases paycheck deductions when the total amount has been repaid.
- Payroll register - summarize employee earnings and deduction information in a journal entry inserted into the general ledger for accounting and general research purposes. Create tax reports.
- Manual payments - issue manual paychecks between pay periods from termination or a payroll error. Account for check amount in payroll register for tax and reporting purposes. Ensures employer’s tax withholding amount reconciles with employee deductions.
- Archive management - store payroll records for future inquiries and reporting.
- Monthly IRS submittals - submit Federal tax information.
- Monthly Labor Department submittals - submit monthly reports to Department of Labor, for hours worked but labor category, overtime, and other attributes of the labor force.
- Monthly State submittals - submit State tax information.
The question that would be asked by the payroll manager to the development team would be ...
When can we use the system to pay people in the compliant manner we are required to by Federal and State(s) law? When can we Go Live with this payroll systems you are building one story at a time and delivering daily?
The Fallacy
Without a product roadmap and release plan for each Feature to implement each Capability, the users of the payroll system have no idea when they can start running payroll?
Here's how to get working software for a State Healthcare enrollment system out the door every Thursday evening, ready for production the coming Monday morning with the business opens for business using Scrum and XP. There is a Product Roadmap, a Release Plan, a Plan of the Week, and a Plan of the Day. All these Plans are focused on delivering the needed business Capabilities, at the needed time, for the needed budget.
So yes, the daily release of the software is a good idea - that's the paradigm of the Plan of the Day. But that Plan rolls up to the Week, Release, and Capabilities plans. All operating in the presence of uncertainty. And all requiring estimates to be made on a daily basis for the next level of outcomes and success.
All these plans answer the question that is asked every day, when can we go live? But is that question is answered by developing and releasing one story at a time? If so, where are the numbers for dates, costs, and delivered capabilities? Developing and releasing one story at a time on a daily basis may be an enabler of the larger picture, but where is the larger picture?
The suggested approach in the original tweet is like the blind men searching the parts of the elephant looking for the payroll system. They can't see the whole elephant, they can't know when all the parts of the elephant will come together to be an elephant, They're in the dark, with no vision of what Done looks like in any units of measure meaningful to the decision makers.
If you don't have a plan to produce the needed capabilities at the needed time for the needed cost, then you're likely working on a de minimis project and no one cares if you're estimating or not. You're just like the blind men, wandering around trying to figure out what your working on and what the result will be.
