Feedback after using Scrum agile method
In this article, I will share with you my feedback on the scrum methodology. This is not a guideline or critic of this method, but just my feedback.
Context
I start discovering the scrum methodology in 2012 with a professional training to be scrum master. At that time, I was very curious to discover new ways of managing software project.
Discovering the scrum methodology was very helpful in my day to day professional life. At that time, I was very enthusiast about this new way of working, and today, 10 years after, I continue to work with that type of methodology even in a small project.
After 10 years around this methodology and 5 years of intensive use of this method, I think it's time to share with you my feedback about this methodology.
But what is the scrum agile method.
This post is not a guide for this method, but for people who didn't know about this, here is a quick guide:
My feedback
The story point
How to evaluate a story point is not defined in the scrum guide. This definition is let free for the team.
The most common definitions are :
A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. Difficulties could be related to complexities, risks, and efforts involved.
In most cases a story point uses one of the following scales for sizing:
• 1,2,4,8,16
• X-Small, Small, Medium, Large, Extra-Large ( known as “T-Shirt Sizing”)
• : 1,2,3,5,8,13,21
With this representation, it's really hard to understand what represent a story point. It is harder when you work on a project with various tasks and environments. Can you compare a us on fix a PostgreSQL issue and add a new exchange protocols ? What will be the reference you need to change between this two.
So, to avoid all of this, we decided to simplify the abstraction:
Our story points are defined as the estimated time that we will need to do this task in an ideal world. An ideal world means that I spend 100% of my time doing this. In the real world this never arrives, so this is our abstraction.
And we use the Fibonacci sequence with a real card game. Or with this application in remote.
The advantage is that the product owner have a good estimation of the time spend by the team on the project, and the abstraction is real.
Planning Sprint
During a retrospective, one subject has come from the team. The quality. The global feeling of the team was that the quality was poor in the scrum, and not in the center of this method. That's right, so how do we improve that?
We had the idea to create a new ceremonial that we called planning sprint.
This ceremonial happened next to the planning poker where we discuss about the specification with the stakeholder. In this meeting we only discuss about quality issues, and we highlight the things that the team needs to do on each user story regarding the quality (do we need conception? what type of tests do we need?).
The team appreciate this ritual because we have some dedicated time to think about technical and quality issues and not only the specification part.
Conclusion
I thing this methodology stay the best way to work in a software team. But you need to be careful about the quality and the architecture part. The global scrum guide didn’t mentionned anything about this and nowadays, the quality of the software delivery is a major point.