In the last 5 years, I’ve worked in projects under SCRUM, and in most of them the same questions and comments have risen:
Why did you put that many hours if it took you less hours to complete the task? Finishing an activity can’t take you longer that what you’ve estimated, why didn’t you add all the task that you’ll need in advance? along with other whys and useless comments.
Estimation and SCRUM make the
With all these scenarios I came to realize the following: The beauty of SCRUM is, everything is an estimation. The not so beautiful part of SCRUM is… that everything is an estimation and not everyone understands that. So here are some things my team and I applied in past and current projects:
- Create the stories as detailed as possible.
- Add acceptance criteria to your stories.
- Is the story too big to be completed in a single sprint? If so, let’s split the story in multiple stories by functionality or flow.
- Does the story have too many points? Let’s do the same as the previous point, let’s split it by functionality. That way, we can control the sprint points and the functionality easier.
- Something didn’t go well in the sprint? Let’s review what happened and how it can be solved instead of finding someone to blame
- Be honest in your retrospective, speak of what went well and what didn’t. If there were troubles, what do you think can be improved and how?
Last thing, remember we all are a team, Devs, QA, design, DBA, etc. Throw away that old (and dumb) idea of us versus them or Dev vs QA, because that’s not how this works. We are all in the same boat, and we share the same goal, which is to deliver a high-quality product.
I hope my experience helps your transition to SCRUM to be a bit easier, and helps you understand what can be done and accomplished.