We've been using ShapeUp at Zinc Learning Labs for over a year now. It has helped us grow into a calmer, more efficient team with dependable outcomes. I plan to write about our experience over a few posts like these. I hope that articulating these thoughts will be useful to anyone considering ShapeUp for their projects and also help us better understand our own journey.
My favorite part about embracing ShapeUp has been to (finally) stop worrying about estimation. Of all the non-coding tasks that I've had to do, I enjoy estimation the least. I am not alone here, am I?
Over the years, I've found that estimation tends to be accurate only when all these things are in place:
My favorite part about embracing ShapeUp has been to (finally) stop worrying about estimation. Of all the non-coding tasks that I've had to do, I enjoy estimation the least. I am not alone here, am I?
Over the years, I've found that estimation tends to be accurate only when all these things are in place:
- Well thought out and clear requirements
- All possible edge cases and an approach to deal with them
- A fully finished design
- A fairly detailed technical solution
While having well thought out requirements is very valuable, the rest of the points are not only hard to achieve, they also inhibit the creativity of the programmers/designers who will eventually work on the solution. The pitfalls of doing too much upfront technical design is well known and a definite no-go. Of course, most of us don't (and shouldn't) go to this extent for estimation, we do it based on a subset of this information, based on what we know.
How do we deal with unknowns and uncertainty then? In the early days of my career, we dealt with them by adding buffers to the estimates. Later, we started using "story points" and "velocity". I loved that "velocity" measured and respected the team's pace but it never proved to be the consistent measure it aimed to be.
ShapeUp recommends that we think about "Appetite" (how much time do we want to spend on this) rather than "Estimate". Rather than eliminating unknowns or accounting for it with buffers, the techniques discussed in the book, gives you all the tools you need to "wrestle with these unknowns" (as Ryan calls it in one of the ShapeUp Live sessions).
This shifted our thought process from hoping that there are no unknowns to being armed with techniques to deal with it, "scoping" being the main one. We had many instances when they were unknowns (read "unplanned and time-consuming side-effects") which could push our overall release date by a week, sometimes two weeks. Rather than pushing the release date, we got really good at scoping out the right pieces of the feature, rethinking what can be delivered in the given time and never compromising on the deadline.
Scoping the feature to deliver it in the given time is a skill we had to develop. It wasn't easy but we got better at it every cycle. Delivering a feature on time feels so good :) It turned out to be a really great incentive for us to develop this skill.
How do we deal with unknowns and uncertainty then? In the early days of my career, we dealt with them by adding buffers to the estimates. Later, we started using "story points" and "velocity". I loved that "velocity" measured and respected the team's pace but it never proved to be the consistent measure it aimed to be.
ShapeUp recommends that we think about "Appetite" (how much time do we want to spend on this) rather than "Estimate". Rather than eliminating unknowns or accounting for it with buffers, the techniques discussed in the book, gives you all the tools you need to "wrestle with these unknowns" (as Ryan calls it in one of the ShapeUp Live sessions).
This shifted our thought process from hoping that there are no unknowns to being armed with techniques to deal with it, "scoping" being the main one. We had many instances when they were unknowns (read "unplanned and time-consuming side-effects") which could push our overall release date by a week, sometimes two weeks. Rather than pushing the release date, we got really good at scoping out the right pieces of the feature, rethinking what can be delivered in the given time and never compromising on the deadline.
Scoping the feature to deliver it in the given time is a skill we had to develop. It wasn't easy but we got better at it every cycle. Delivering a feature on time feels so good :) It turned out to be a really great incentive for us to develop this skill.