Scrum Dynamics 28 - Shawn, Stop Estimating Effort in Days
Shawn Tabor, fellow MVP and Principal Architect at Hitachi Solutions America, posts a question on this episode of Scrum Dynamics. Shawn is from Florida — does that explain why he shoots vertical video?
Shawn wants to know whether to estimate Dynamics 365 projects using days or story points, and asks, what’s the difference?
I’ve used four different methods of estimating my Dynamics 365 projects:
Counting cards — if all your stories are nearly the same size, then you can simply count the number of cards in your backlog to estimate your remaining work. Use this method if your team is able to refine stories into similar sized items and your velocity is stable enough that you’re completing approximately the same number of cards in each sprint. It’s fast and it works, but it requires an experienced team so you might want to use one of the other methods first.
Estimating time — this is a common method, especially for teams transitioning from Sure Step to an agile software development approach. With this approach, the project manager or architect breaks down the work into tasks in the work breakdown structure and each task is estimated in hours to arrive an at overall estimate of effort for the project. Rolling that into an agile approach involves estimating the effort of each product backlog item in hours or days. Time-based estimation takes a lot of time, especially in pre-sales situations.
T-shirt-sizing — to protect our stakeholders from complex, unfamiliar concepts (like numbers) some teams use t-shirt sizing to estimate stories. The benefit of t-shirt sizing is that it is a relative estimation method; we compare the relative effort of two items and assign t-shirt sizes to each one. The downside is that we can up the sizes of stories into a meaningful number. Imagine we’ve got 6 smalls, 4 mediums, 2 larges and an extra large left before our first release to production — what does that even mean?
Story points — my favourite and recommended estimation method is to use story points. Story points are arbitrary units of relative effort (or relative complexity). A one-point story will usually take half as much effort (or is half as complex) as a two-point story. Story points are easy to learn, use relative estimation, are faster than time-based estimation, and are flexible when our definition of done or team composition changes. What’s not to love about story points?
How does your team estimate its Microsoft Business Applications projects? Are you using one of these four methods? A variation or a different method altogether. I’d love to know in the comments below.