Hi My name is Ganesh and I am here to talk about SCRUM, Scrum is a heavily used framework in the software development industry today.
Let us learn about SCRUM by answering a few questions like what is scrum, and why we need to use scrum. Before we begin let us understand the problem SCRUM solving.
The Waterfall framework was a widely used framework before SCRUM. This methodology dictates that software development should happen in multiple stages like defining scope, development, testing, and maintenance. These stages are nonlinear which means so very little scope for continuous improvement. It also had many challenges around scope, timelines, and communication. These things take time so by the time product is released your customers might find alternatives, or your competitor beats you to the market.
Solution: SCRUM in a nutshell
Scrum helps to overcome these challenges by dictating an iterative model of delivery. which means you will slice your entire project into meaningful pieces that can work independently or together, then pick some feature/key element built and ship it to the customer in an iterative manner. Each iteration can be 2 to 4 weeks in duration. After each delivery, you will have feedback to add to your backlog, Next pick the next set for the next iteration. Repeat this until all the features are delivered.
This way you could reach your customers quickly with the minimum or key features. This way you will have better and more accurate insights from the actual users and that will l help you build the complete project with clarity. Of course, this process will disrupt many things like cost, plan, and estimates but It is better to fail fast than fail big right?
Know that we are familiar with SCRUM let us take a close look at SCRUM. SCRUM is simply a guide with roles, rules, and routines in it. At least I look at the scrum that way.
What are SCRUM Roles?
A typical scrum consists of 3 roles with a size of 3 to 9 members, the roles are SCRUM Master, Product Owner, and Developers. SCRUM Master acts as a coach to the team, he facilitates, helps, and educates the team to work towards the goal and deliver. he will work towards eliminating any potential blocker for the team. Product Owners acts as captain he will help the team with the plan, prioritize, and provides directions to the team. Developers are the ones who build the software, test, and deliver.
As we discussed earlier. When the SCRUM team picks a set of items to develop and deliver and start then the iteration is constant. This means no shrinking/pausing or postponing.
Time-box each of the meetings, never fail to attend meetings and each iteration should produce the shippable software.
SCRUM has a few mandatory routines, One of them is the Sprint planning meeting, in this meeting all the team members together plan the work and decide the goal they want to achieve at the end of the iteration or sprint and then start the sprint.
During the sprint days, every day all the team members quickly meet for 15 minutes and talk about their progress and talk about any blocker, this way all the team members know the exact state of the sprint on any given day this meeting is called Daily SCRUM.
During the spring team spends time in backlog refinement meetings that will focus on creating work items for future sprints by dividing the features.
Once the sprint is finished and the goal is achieved there could things went well or went sideways, so the team will again come together and discuss the things that happened during the sprint, this exercise will result in action items to follow in the future sprint so the team gets better by each iteration.
We have discussed a lot of SCRUM items it’s time we put them together in an official SCRUM workflow diagram.
Thanks for reading please do comment or share the article!
Top comments (2)
you've explained it very well. In reality scrum is often used as an excuse to abandon structure and all documentation, as most projects do not use scrum and other agile principles in the correct way. :/
I overcome this particular challenge with the PBI quality agreements, I asked the developers or POs not to fail to write INVEST criteria, User story, Acceptance criteria, PBI Goal, and PBI Background. That solved the problem. The team has all the info on PBIs a well-indexed documentation :-).