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 story, 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 Scrum framework.
Let’s understand what is Scrum and 11 elements of Scrum before talking about all these.
Scrum framework consists 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 scrum guide for further clarification.
There are five explicit events in Scrum and one implicit event. Below is the short description of these events. Explicit because clearly defined when these events occur and implicit means team decide when to have that event.
This is a time-boxed of one month or less depends on various factors but especially 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 pace and also don’t change team members frequently. Changing team member is allowed but must consider the impact on productivity when change team member.
Sprint contain and consist all other events so you may call it as container event. During the sprint, no changes are made that can alter the definition of 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 get decided by various factors. Best possible way to decide is to have the right balance between 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 barrier and regulatory issues etc.
Development team prepare plan during Sprint planning for work that will get done during a sprint. Sprint planning is 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 4 hours of the planning session. Even 2 weeks sprint can have 6 hours of sprint planning if needed.
If 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 the definition of DONE. Team craft sprint goal and prepare detailed plan to meet sprint goal. Elevator pitch is a very useful tool to create sprint goal. Forecasted PBIs along with detailed plan called Sprint Backlog. The team discuss approach and design to complete PBIs that get reflected as tasks on 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 beside than scrum board.
More elaborated definition of DONE and improvement initiative may have an influence on sprint forecast during sprint planning.
Who attends this event? Scrum team (product owner, scrum master and development team) and sometime SMEs (subject matters expert).
Sprint planning becomes very cumbersome event if more than one development team working on the same product. That’s where some Scaling Scrum framework helps. Like LeSS suggest 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. These framework makes more sense when you have more than 25-30 developers working on same product but this is my personal opinion.
A time-boxed event for 15 minutes occurs every day for the development team to inspect work done from last Daily Scrum. Development team inspect work and prepare a plan to adapt for next 24 hours (before next daily scrum). Daily Scrum takes place at same time and 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 their own daily scrum if multiple teams working on the same product. Team may have open house session frequently to coordinate dependencies with other teams.
– Review held at the end of the sprint to inspect product increment and adapt product backlog. A review is 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 agreed time-box.
There are three things that happen during sprint review event.
Report – 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 discuss 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 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 increment in case there are multiple teams working on the same product.
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 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 participate as a team member to review 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 the 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. Depends on team and coordination between teams.
This is an event to perform below activities and attended by product owner and development team.
Understand new PBI – PO explains about newly added product backlog item and team ask 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 sprint duration. There are some techniques to split and most popular technique is 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 write use cases and usage scenario to understand the size of PBI.
Estimation – Estimating PBIs based on team consensus so product owner 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 – Product owner orders PBIs with consultation with a development team. The team helps PO to understand 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 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 this articles to read about roles and artefacts.