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)…
Most Agile teams plan work for an iteration by assigning points to user stories and selecting as many stories off the top of the priority queue as will fit within that team’s projected velocity for the iteration. In larger projects, the stories are often written and prioritized by a project manager or some other person who has a vested interest in the success of the iteration but is unlikely to be implementing the stories themselves.
When story point estimation goes well, the iteration planning meeting is a valuable communication tool that allows the development team and outside stakeholders to align expectations for the iteration. When stories are poorly estimated, however, things can go very badly. Developers are hurt when they get little recognition for hard work, and project managers suffer when what seemed to be a reasonable plan fails.
Read more on Scouting Your User Stories…
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…
When did you last prune your backlog?
When you started the project, the team sat together for a planning poker session to provide the initial definition of the project. Now it’s six months later – or six weeks or even days later. You’ve been paying attention to the stories in your current iteration. Have you thought at all about the items in your backlog?
Read more on Prune Your Backlog…
The worst possible budget for a project is zero. If you have no funds or no time, you have no power to build anything worthwhile. That’s not a surprise to anyone – no one likes working under absurd constraints.
The second worst possible budget is unlimited.
Read more on An Unlimited Budget Is Almost as Bad as No Budget…
Every project has its challenges. Sometimes the challenges are technical, such as unfamiliar or immature technologies, and sometimes the challenges come from the business, such as people, schedule, or money. Over the past year or so, I’ve finished a couple of projects where the challenges were small size, short timelimes, and limited budgets. I’d like to share some of the lessons learned from that work. These lessons come from projects with initial development phases in the range of 3 – 6 person-weeks.
Read more on Agile at Scale – The Small Scale…
A couple of years ago I wrote about how I was using Epic stories for early project estimations. Recently John Rusk posted a question in the comments:
I have a question about this: “We make no attempt to restrict that the total number of points from the resulting stories adds up to the previous estimate of the Epic”.
How do you find that affects your burn charts? In particular, imagine you are half way through a project. All the epics up to that point in the project have been “expanded” into smaller user stories. But the epics after that point have not yet been expanded. Imagine also that, when expanding an epics, the total number of points in the small stories is typically greater than the total of the original epic.
This would mean that past work has reasonably accurate numbers of points associated with it, but that future work, still in epic form, is underestimated. (Since, when you decompose the future work, its point value will typically go up, so therefore its current point value is too low).
If this happens, it may skew your burn charts and make you think you’re closer to finishing than you really are.
However, from your description of your success with this approach, I take it that this problem doesn’t actually affect you. I have used a similar approach myself but, being concerned about the above problem, I have always taken care to preserve the same total point value when breaking down the epics. Hence my interest in hearing how you have tackled, or avoided, the same problem.
I am using Epics to get a very rough estimate of the size of the project, without having to spend an inordinate amount of time wading through the details at the beginning of the project (at the point of maximum ignorance as Carl is fond of saying).
Read more on Breaking Down Epic Stories…
Atomic creates custom software for our clients. Our work ranges from greenfield web application development to creating backend data-centric applications. In most projects, we work with multiple technologies and we integrate with other systems. We’re not experts in every technology, but we’re experts at becoming experts with any technology we work with.
Read more on Fixed-Budget, Fixed-Scope, High-Quality Custom Software…
Vendors may use the phrase “time and materials” (t&m) to describe how they engage in projects and invoice their clients.
The phrase t&m has been laid to rest at Atomic for several reasons. First, the phrase doesn’t accurately describe how we engage with our clients. At Atomic, we certainly don’t work without profit. And we have an innate desire to be more efficient.
Read more on A Responsible Alternative to Time and Materials…