estimating
 |
Using Points and Hours for Estimating Steve Berczuk writes that if you decide that there is some value to estimating, you have to decide which unit to measure with points, hours, or something else. Without estimation of any kind, it's difficult to understand how effective you can deliver. |
|
 |
Calculating the Real Cost of Multitasking on Your Projects The cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of time lost due to context switching; it’s the fact that projects don't get out on time, which hurts your maximum sales revenue. How do you calculate these costs of delay? |
|
 |
How Agile Teams Can Deal with Estimation Agile teams often struggle with estimation. As essential as the concepts of measurement and feedback are to agile software development, the concept of "estimation" seems to stir memories of non-agile projects, and it provokes fears of excessive process. |
|
 |
The Truth behind Software Development Estimates The problem with estimation is that software is not construction. We can’t create software the same way we build a house or manufacture anything else. We can't say, “We can build this software for x dollars per square foot.” But other people often think of our estimates that way. What can you do? |
|
 |
Quitters Sometimes Do Win: How to Recognize and Confront Sunk Costs From Freakonomics coauthor Stephen Dubner: "A ‘sunk cost’ is just what it sounds like: time or money you've already spent. The sunk-cost fallacy is when you tell yourself that you can't quit because of all that time or money you spent. We shouldn't fall for this fallacy, but we do it all the time." |
|
 |
Remember: Your Goal Is to Solve Your Customers' Problems Steve Berczuk reminds us that while estimation, process, and technical skill are essential to delivering value to a customer in a cost-effective way, they are just means to your primary goal of solving problems. |
|
 |
Mastering the Black Art of Software Project Estimation Estimation at the start of a software development project doesn't have to be done blindly; nor does it have to involve making empty promises. By incorporating agile—or even an estimation center of excellence—both customers and developers can have a much clearer view of the road ahead. |
|
 |
What Team Members Get Wrong with Retrospectives Venkatesh Krishnamurthy explains some common misconceptions with retrospectives. Having a rigid mindset and believing that teams should only do retrospectives at the end of an iteration or raise issues only during standup meetings reduce agility and result in process-oriented thinking. |
