3 ms·
Well yes. I suppose the problem is people think they are being agile when they actually have a 6 month backlog of user stories and won't release anything for mo
by benjiweber 12y ago
Well yes. I suppose the problem is people think they are being agile when they actually have a 6 month backlog of user stories and won't release anything for months.
In that scenario estimating things becomes very tedious and not particularly useful.
- wlievens 12y agoBut what if you actually have a 6 month backlog of real user stories? As in, you know these requirements pretty well, for instance because you're re-implementing a legacy system?
- dreamfactory2 12y agoWhat's the difference then between the new system and the legacy one?
- wlievens 12y agoIn this hypothetical scenario? Any number of nonfunctional requirements.
- dreamfactory2 12y agoSo no added business value can be conveyed in stories?
- wlievens 12y agoSure it can. User story: "The software is orders of magnitude too slow. Rewrite it from the ground up using scalable technologies."
- dreamfactory2 12y agoPoint being that it isn't a rewrite but a new piece of software.
- wlievens 12y agoIf you're implementing, say, a general-purpose accounting system, from scratch, then I think your requirements and feature set is well known beyond the "a few weeks" horizon, and planning that feature set months in the future is not unreasonable.
- dreamfactory2 12y agoActually wouldn't agree with that example. Accounting systems are very diverse e.g. Sage, Wave, Freeagent, SAP, Excel+Access.
- benjiweber 12y agoI would prefer not to do re-implementation of a legacy system as a project. For a start legacy systems often have a lot of dead features that nobody uses any more, so we risk wasting time implementing things nobody needs. A 6 month backlog also sometimes means a build-it-all and release approach which means 6 months before we start using the replacement in production. I prefer to take a strangler application approach http://martinfowler.com/bliki/StranglerApplication.html http://martinfowler.com/bliki/StranglerApplication.html Start replacing small parts of the legacy system in production as rapidly as possible. Then move across bits of functionality bit by bit until enough functionality has been moved to turn the old system off. This also allows you to rapidly get benefit from new functionality that the old system did not have, or improved performance for the most critical parts of the system, without getting bogged down in implementing lots of rarely used features. I would constantly be looking for the highest value features to add or replace from the old system and use estimation as a tool to aid prioritisation of those.