Buying custom software design and development services, especially for the first time, can be scary. There is clearly a knowledge imbalance between you and your service provider. They (hopefully) understand the effort required to successfully build your product, and you don’t. This puts you at risk of being taken advantage of.
I understand this fear. Any time my car is in need of repairs, I am paranoid that the mechanic will take me for a ride. Other than being able to drive a car, I know very little about them. There is a clear imbalance between my and the mechanic’s understanding of labor and parts costs. This puts me at risk. Read more on Why You Should Trust your Software Vendor – From a Guy who Fears the Mechanic…
I gave a talk entitled “Time-Based Estimates Are For Suckers! Size-based is The Way to Go” at this year’s GLSEC on April 29. It’s meant as a call to action for those who haven’t made the leap to size-based estimation, or who have been beaten back by some of the challenges you’ll encounter when trying, such as:
- Breaking things down by value, not by task
- Thinking in terms of “size” (not time)
- Making estimates
I did this because, even though we’re all a bunch of Agile know-it-alls by now, and estimation is a remedial topic from 10 years ago, there are still plenty of people who haven’t been introducted to size-based estimation. Besides, making the switch from time-based estimation to size-based isn’t as easy as some of the books and blogs out there make it sound.
Read more on Time-Based Estimates Are for Suckers! (Size-based Is the Way to Go)…
If your team is not focused on delivering intermediate project milestones, they are missing what’s really of value. It’s easy to miss the forest for the trees if you’re only focusing on task-level points estimates and velocity tracking.
I’ve become frustrated with how burn charts focus on showing progress through an entire backlog and don’t clearly show the importance of incrementally delivering chunks of value.
Burn Charts Are Not Enough
Atomic has been experimenting with several approaches to help us focus, report against, and manage scope against intermediate milestones.
Read more on Moving Beyond Story Points, Iterations, and Burn Charts…
For 10 years, I thought I was a very good project manager. By very good, I mean that almost all of the projects I led were delivered near scope and on schedule. There were no death marches of overtime, and we pushed the technology envelope. Overall, we enjoyed the work.
It was not without its stresses. There were always big issues with customers, team members, and technology that, if not solved, would certainly cause failure. There were many short bursts of overtime, especially to meet the final deliverable. And then there was the constant frustration and time spent re-planning the project to keep things on track. But isn’t this what project management is all about? And isn’t delivery as promised (without a body count) a fantastic thing in our line of work?
Well, I thought so, until I attended a small conference and learned something at one of the sessions so fundamental it was embarrassing.
Read more on Getting Reschooled in Project Management – How to Plan a Project with no Multi-Tasking…
Part of a series on Making better estimates.
The team needs to own the estimate, so the team needs to make the estimate.
If you’re estimating with the team, then you need to work to consensus on each chunk you’re estimating. The conversation that comes out of differing opinions on the complexity of a task helps reveal the nature of that task, the diversity and importance of assumptions, and the range of optimism within the team. The results improve from simply talking about all this stuff.
Read more on Making Better Estimates, Part 2: Team Estimates…