6
You don't convert story points into money. The cost of a software development effort is a function of the team for a period of time, perhaps considering resources if you forward those costs along. However, story points do not convert to time, so you cannot use them as an input into cost. Story points are also highly volatile, so even if you tried to convert ...
5
Building an application piece by piece using Agile Development means you do not build what you do not need, but you still need to design the architecture for the application.
When I see a code base become a patchwork of enhancements with little technical direction I see a number of issues that should be addressed:
A lack of technical leadership on the team ...
4
Story points at least arguably should never leave the team room -- it's not something higher-ups need to know.
However, if they hold your feet to the fire and insist on a number, and if you've been at it for a while and your team has delivered a product before, just do basic math. Add up all of the story points for the past six or twelve months, and divide ...
3
Story points are supposed to be abstract, they are only ever intended to be used as a relative measurement that is quick to estimate. Once you attempt to translate story points into a cost (e.g. 3 points is 15 hours) you get a false sense of accuracy, and your estimates become much harder to come to a consensus on.
If you need to give time / cost estimates,...
2
What you describe is what Martin Fowler calls Flaccid Scrum.
The only solution to this that I can agree with are eXtreme Programming practices:
Test Driven Development
Relentless Refactoring
Pair Programming
Trunk-based development
Continuous Integration
Evolutionary design
And in general, focus on discipline and technical excellence. You must simply ...
Only top voted, non community-wiki answers of a minimum length are eligible
