TL;DR
In the previous post, we find out how not to make a standard milestone error, making milestones about functional activities and not about deliverables. Today we put perspective on how little instead how much can we estimate. The post is based on a remarkable book written by Johanna Rothman, Manage It!
How Little Vs. How Much
A common trap in project estimates is to think about team upper limit, how much could be done by the end of the milestone. Team members are seen as infinitive “resource” (terrible word selection for naming people), and the schedule is not essential and could be broken. The team could start immediately banging on keyboards and produce code as requirements are always crystal clear.
We must squeeze in this requirement, and it is ok to break the milestone by Friday (thinking about the weekend as two extra working days) [project manager name known to author].
The cost of development is not the first factor because we must do as much as possible.
In how little, we take baby steps. Take small chunks of requirements and start implementing them so we could check our understanding of what should be developed. Schedule and milestones are kings, as development cost is the top priority, and rescheduling is expensive.
Remember
While your team velocity is unknown, make a little in your sprints. Leave enough buffer in your schedule. As you measure velocity and team become confident in the way of working, increase a little what should be done as milestone delivery.
