Scrum is a lightweight software development framework but how much light? I often see people add too many things and make it monster. I usually ask participants in my Scrum Developer workshop to write down all those keywords, elements and buzzword that comes in 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, definition of ready and agile coaching etc. All these are 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 artifacts. Yes, scrum only have 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 team. If those are helping you then continue but be clear that those are not part of scrum. I will suggest to refer scrum guide for further clarification.
There are five explicit events in Scrum and one implicit event. Below is 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. Potential releasable product increment as per DONE get created within sprint. Must have 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 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 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 right balance between Cost of Production and Cost of Delay. Other factors get applied as well based on domain in which you are operating. Those factors can be knowledge about engineering practices, culture barrier and regulatory issues etc.
Development team prepare plan during Sprint planning for work that will get done during sprint. Sprint planning is time-box event for 8 hours or less for 30 days sprint. Shorter sprint may having shorter sprint planning duration. That doesn’t mean 15 days sprint can’t have more 4 hours of planning session. Even 2 weeks sprint can have 6 hours of sprint planning if needed.
If Team refine product backlog continuously for future sprints and able to remove ambiguity in requirement then sprint planning may take lesser time.
During sprint planning, team picks up PBIs based on team capacity or velocity as well 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. 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 as team progress.
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 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 become very cumbersome event if more than one development team working on same product. That’s where some Scaling Scrum framework helps. Like LeSS suggest to divide sprint planning in 2 parts whereas Nexus suggests to have a separate Nexus Integration Team. I have seen teams working fine even when there was 4-5 teams working on 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 development team to inspect work done from last Daily Scrum. Development team inspect work and prepare 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 known as stand-up meeting.
During Daily Scrum every development team members explain below:-
What I have 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 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? Only development team is required. Yes Scrum Master can attend but not for taking status. Impediments get reported not only in daily scrum but actually it get reported as soon as identified. Every team runs their own daily scrum if multiple teams working on same product. Team may have open house session frequently to coordinate dependencies with other teams.
– Review held at the end of sprint to inspect product increment and adapt product backlog. Review is 4 hour time-boxed meeting for a month long sprint. Shorter sprint usually will have shorter duration. Scrum master teaches team to keep this within agreed time-box.
There is three things that happens 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 about 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 sales people etc.)
This is not an event for PO to accept work done by team. PO accepts work during development as soon as PBI is done. This for stakeholders so stakeholders are identified and invited by product owner.
Team should demonstrate integrated product increment in case there are multiple teams working on same product.
I usually prefer to call it a Kaizen session. This is the event that make Scrum more interesting. 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 facilitate but also participate as team member to review Scrum process.
Scrum team cheers for success, brainstorm for failure and create plan for improvement. Retrospective should not very serious or very light but must be fruitful session. To make it more fruitful, team play some game, collect data and generate insight and come up with 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 to write all possible scenarios for PBIs because that helps in splitting. Some team write use cases and usage scenario to understand 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 absolute number using bottom-up estimation or 3 points estimation.
Ordering PBIs – Product owner orders PBIs with consultation with development team. Team helps PO to understand technical dependency of PBI and PO usages some prioritization techniques such as MOSCOW and KANO model etc.
This become massive work when multiple teams work on 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 product owner.
Wait for part -2 of this articles to read about roles and artifacts.