|
Estimating Cost of Delay in Agile Projects with Time-Value Profiles The cost of delay for releasing a product can be due to many factors, but that value loss can seem like an abstract concept. Attaching hard numbers to a release timeline in the form of a time-value profile helps the development team and business stakeholders have a conversation about how long they have to build a product and when it would be best to enter a market.
|
|
|
Reduce Uncertainty in Agile Projects with #NoEstimates Thinking Estimation uncertainty in software projects is often not driven by the difficulty of the problem we are trying to solve, but rather by the health of our codebase, the quality of process, and how much discipline we have in our management practices. If you want to improve your estimates, then agile and #NoEstimates thinking can have the biggest impact on your team’s success.
|
|
|
Delivering Value with Agile and #NoEstimates #NoEstimates is a challenge to the traditional thinking that estimation is essential to agile development. Ryan Ripley believes there are more interesting tools available to help us determine what value is and when we could realize it, while still staying aligned with the businesses and customers we serve. Learn some other ways to deliver value to your customers.
|
|
|
Estimation: What It Takes to Deliver Consumable Value in Agile Projects Releasing in small batches is a good way to achieve quick feedback in your sprints, but these pieces don't have all the features users need. Providing consumable value is turning those small bites into a meal, and it’s worthwhile to estimate what it will take to deliver that—asking, “What consumable value do we expect to achieve, what duration and cost should we plan for, and how likely is it that the plan will succeed?”
|
|
|
The Effect of Time on Value in Your Agile Projects Using effort estimates as the only criteria for deciding whether work is undertaken could be leaving money on the table. Considering value—in particular, the effect of time on value, as in whether there is a cost of delay—makes for more intelligent conversations and better decisions.
|
|
|
Estimating Business Value in the Shark Tank You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.
|
|
|
Stop Re-estimating Your Stories for Every Iteration Many agile practitioners recommend re-estimating stories at the beginning of each iteration to increase accuracy. Adrian Wible, however, argues that re-estimating stories within an iteration planning meeting actually distorts results and decreases predictability. See if you need to rethink your planning procedures.
|
|
|
Help Your Team Understand Its Iteration Burndown A good key indicator for measuring how well your agile team is performing is the burndown chart. It’s a simple concept—as time passes, the amount of work to do decreases. Of course, there will be days when progress is not as expected or tasks end up larger than originally estimated. A burndown can help your team reset and keep stakeholders in the loop.
|
|
|
User Story Points versus Man-Hours: Estimating Effort Better Effort estimation is a major challenge for all the stakeholders of a project. Most people generally underestimate situations that may block progress and consider only the best-case scenario for a project. Your choice of estimation method may not be helping, though. Which would be better for your team: estimating by man-hours or by user story points?
|
|
|
Help Your Team Understand Its Velocity Teams should be working toward a target velocity that is based on historical evidence. There may be times when this figure needs to be adjusted, but teams that understand their velocity know that it is a good indicator of what they are capable of achieving in a sustainable way, and this will increase confidence for the teams and stakeholders.
|
|