What is Scrum?
A scrum is a lightweight software development framework but how much light? I often see people add too many things and make it a monster. I usually ask participants in my Scrum Developer workshop to write down all those keywords, elements and buzzword that comes to mind or you have heard so far. What they write is always mind-blowing. Who is teaching/promoting those keywords? They start writing things like user stories, planning poker, story points, agile estimation, release train, epic, burndown, release planning, DevOps, the definition of ready and agile coaching, etc. All these are the part of Scrum? Seriously? These may be helpful for you but not part of the Scrum framework.
Let’s have a look at the these may be helpful for you but not part of the Scrum framework. Scrum guide and understand what is Scrum and 11 elements of Scrum before talking about all these.
Scrum framework consists of 5 events, 3 roles, and 3 artefacts. Yes, scrum only has these 11 elements and nothing more. Oh, wait there are 2 more implicit elements. Definition of Done and Product Backlog Refinement. So all above not needed if not part of Scrum? May or may not and depends on the team. If those are helping you then continue but be clear that those are not part of the scrum. I will suggest referring the scrum guide for further clarification.
What are the Scrum Events?
There are five explicit events in Scrum and one implicit event. Below is a short description of these events. Explicit because clearly defined when these events occur and implicit means team decide when to have that event.
1. Sprint:
This is a time-boxed of one month or less depends on various factors but especially the cost of delay and cost of production. Potentially releasable product increment as per DONE gets created within the sprint. Must have a consistent duration of sprints in order to have sustainable peace and also don’t change team members frequently. Changing team members is allowed but must consider the impact on productivity when change team members.
Sprint contains and consists of all other events so you may call it a container event. During the sprint, no changes are made that can alter the definition of the sprint goal. Quality must be met as agreed and usually defined as part of DONE but scope may be clarified or re-negotiated between product owner and development team.
Sprint duration varies from team to team and duration gets decided by various factors. The best possible way to decide is to have the right balance between the Cost of Production and Cost of Delay. Other factors get applied as well based on a domain in which you are operating. Those factors can be known about engineering practices, culture barriers, and regulatory issues, etc.
2. Sprint Planning:
The development team prepares a plan during Sprint planning for work that will get done during a sprint. Sprint planning is a time-box event for 8 hours or less for 30 days sprint. Shorter sprint may have shorter sprint planning duration. That doesn’t mean 15 days sprint can’t have more than 4 hours of the planning session. Even 2 weeks sprint can have 6 hours of sprint planning if needed.
If the Team refines product backlog continuously for future sprints and able to remove ambiguity in requirement then sprint planning may take lesser time.
During sprint planning, the team picks up PBIs based on team capacity or velocity as well as the definition of DONE. Team craft sprint goal and prepare a detailed plan to meet the sprint goal. Elevator pitch is a very useful tool to create a sprint goal. Forecasted PBIs along with a detailed plan called Sprint Backlog. The team discusses approach and design to complete PBIs that get reflected as tasks on the sprint backlog. Sprint backlog may or may not have all the tasks to begin development but tasks get further added/removed from team progress.
A team may also choose some metrics such as sprint burndown to help them keeping track of team progress besides the scrum board.
A more elaborated definition of DONE and improvement initiative may have an influence on sprint forecasts during sprint planning.
Who attends this event? Scrum team (product owner, scrum master, and development team) and sometimes SMEs (subject matters expert).
Sprint planning becomes a very cumbersome event if more than one development team working on the same product. That’s where some Scaling Scrum framework helps. Like LeSS suggests dividing sprint planning into 2 parts whereas Nexus suggests having a separate Nexus Integration Team. I have seen teams working fine even when there were 4-5 teams working on the same product. This framework makes more sense when you have more than 25-30 developers working on the same product but this is my personal opinion.
3. Daily Scrum:
A time-boxed event for 15 minutes occurs every day for the development team to inspect work done from the last Daily Scrum. The development team inspects work and prepare a plan to adapt for the next 24 hours (before the next daily scrum). Daily Scrum takes place at the same time and the same place to reduce complexity and confusion. Daily Scrum also is known as a stand-up meeting.
During Daily Scrum, every development team members explain below:-
- What have I done yesterday that helped the Development Team meeting the Sprint Goal?
- What will I do today to help the Development Team meeting the Sprint Goal?
- Do I see any impediment that prevented me or the Development Team from meeting the Sprint Goal?
The Scrum Master ensures that the Development Team has the Daily Scrum, but the responsibility to conduct it belongs to the Development Team and Scrum Master teaches them to complete it within 15-minute time-box.
Who attends it? The only development team is required. Yes, Scrum Master can attend but not for taking status. Impediments get reported not only in the daily scrum but actually, it gets reported as soon as identified. Every team runs its own daily scrum if multiple teams working on the same product. The team may have open house sessions frequently to coordinate dependencies with other teams.
4. Sprint Review:
Review held at the end of the sprint to inspect product increment and adapt product backlog. A review is a 4-hour time-boxed meeting for a month-long sprint. Shorter sprint usually will have a shorter duration. Scrum master teaches a team to keep this within the agreed time-box.
There are three things that happen during the sprint review event.
-
- Report – The product owner explains the sprint goal, what is done and what is not done.
- Demo – Development Team demonstrate the product increment, answer questions about increment and stakeholders give feedback.
- Forecast – Team discusses what to do next, Product Owner discusses product backlog as on date and also discuss the projected completion date, budget, and potential capabilities.
Who attends it? Scrum Team (Product Owner, Scrum Master, and Development Team) and Stakeholders (Sponsor, Customer, end-user, and salespeople, etc.)
This is not an event for the PO to accept work done by a team. PO accepts work during development as soon as PBI is done. This for stakeholders so stakeholders are identified and invited by the product owner.
A team should demonstrate integrated product increments in case there are multiple teams working on the same product.
5. Sprint Retrospective:
I usually prefer to call it a Kaizen session. This is the event that makes Scrum more interesting. A structured retrospective of everything including how well we have delivered, what we missed, what we could have done better, why product backlog items were not well refined etc. Retrospective not only for the development team but also for scrum master and product owner.
This a time-box event and 3 hours for 30 days sprint. Scrum master not just facilitates but also participates as a team member to review the Scrum process.
Scrum team cheers for success, brainstorm for failure and create a plan for improvement. The retrospective should not very serious or very light but must be a fruitful session. To make it more fruitful, team play some game, collect data and generate insight and come up with the improvement plan for upcoming sprints.
Who attends it? Scrum Team and yes you heard it correctly product owner also attend.
You can have separate retrospective if there are multiple teams as well as combined retrospective. It depends on the team and coordination between teams.
6. Product Backlog Refinement
This is an event to perform below activities and attended by the product owner and development team.
-
- Understand new PBI – PO explains about newly added product backlog item and the team asks questions if they need more clarification.
- Split PBI – Team split PBIs if they feel PBI is big and will not fit in sprint duration. Ideally, one PBI should not be taking more than 20-25% of the sprint duration. There are some techniques to split and the most popular technique is to INVEST (Independent, Negotiable, Valuable, Estimable, Size appropriate and Testable). I also suggest writing all possible scenarios for PBIs because that helps in splitting. Some team writes use cases and usage scenarios to understand the size of PBI.
- Estimation – Estimating PBIs based on team consensus so the product owners can forecast. You like to size PBI by using relative estimation or can go for the absolute number using bottom-up estimation or 3 points estimation.
- Ordering PBIs – The product owner orders PBIs with a consultation with a development team. The team helps the PO to understand the technical dependency of PBI and PO usages some prioritization techniques such as MOSCOW and KANO model etc.
This becomes massive work when multiple teams work on the same product. Many time product owner takes help from business analysts (SME) to manage work at the PO side. These business analysts are not PO and not even proxy PO, they are just extra hands for the product owner.
Wait for part -2 of these articles to read about roles and artifacts.
