A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

New answers tagged

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 ...


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 ...


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,...


1

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 ...


4

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 ...


0

You should apply the open/closed principle and the single responsibility principle This addresses a problem where code increases in complexity and coupling when features were added. In the old way, we would extend the appropriate function by just one more use case. Do this long enough, and you will have long functions containing many use cases which are ...


-1

It sounds like your team needs to do more planning and grooming of the user stories. If you have tasks such as: Write save method for Books Write save method for Authors Write save method for Customers and each developer does it their own way, you've clearly missed the chance to write a generic method (or pick a framework that does it for you). By the ...


Top 50 recent answers are included