SCRUM EVENTS
Let me talk about scrum events as a continuation of my previous post. Instead of just defining all the events (because you can read it as is in scrum guide), I would like to share my personal experience as a PO in a scrum team.
Before addressing each event separately, I want to touch upon the importance of the events. Events are designed to provide the transparency which is crucial to inspect, refine and adapt your artifacts as well as create trust and collaboration between scrum team and stakeholders.
The Sprint
Sprints are the process through which ideas can turn into a value. Sprint goal is the driving force in the sprint and gives a shared understanding to the team. Sprints are fixed length of events and usually last for 2 weeks.
Suggestions derived from my personal experience:
● PBIs need to be clear enough that when they are pulled into sprint, developers can work on it and finish within the timebox.
● A clear and well-defined sprint goal should be determined. Sometimes it is hard to determine a sprint goal for me especially when there are items from different business units (which happens if you are managing a portfolio). In such a situation, I come up with a sprint goal that represents the crucial item in the sprint. The team is ok with that most of the time.
● During the sprint, keep in mind that unexpected work may arise. Ideally, once the sprint is sealed, nothing should disrupt the sprint. However, in reality, sometimes you need to deal with the emerged ones. You can handle with such a situation if you keep buffer in the sprint. In that way, you can make sure that your sprint goal is not endangered and your sprint can be successful.
Sprint Planning
Sprint Planning is carried out by the Scrum team collaboratively. Sprint planning session is the where the sprint value is discussed, how this sprint adds to product goal, and how the chosen items can get done during the sprint. Sprint goal, PBIs selected for the sprint and the plan to deliver these items generate the sprint backlog. Ideal duration for a sprint planning session is 4 hours for a 2-week sprint.
Suggestions derived from my personal experience:
● Take your time to discuss the work items with the team and let them figure out how they can deliver the value at the end.
● Prioritize and order your product backlog accordingly before the planning.
● Keep in mind that during the sprint, unexpected works may emerge. That’s why keep buffer in the sprint and allocate the capacity accordingly.
● Regarding the works in the backlog, make sure that there is not any ambiguity. As PO, before the planning, you should have all the details regarding the work to be done so that the developers can size the work appropriately.
Daily Scrum
Daily scrum is important because it gives chance to inspect the progress toward to sprint goal and align the team. It takes 15 minutes usually and is held at the same time as a ritual.
Daily scrum gives chance to communicate with the team, identify if there are any impediments to be removed and eliminate the need for any other meetings.
Suggestions derived from my personal experience:
● Theory suggests that POs don’t need to be present in daily scrums. However, I highly recommend that you should attend if possible because you have the chance to see if the team is doing ok and getting closer the sprint goal.
● Sometimes, team needs further clarification as they work on their tasks. When they have any question, you can answer and reduce ambiguity.
● It also creates synergy among team members and ensures the team spirit.
Sprint Review
Product owner is the responsible for sprint review and it is crucial to evaluate your increment and decide the adaptations. During sprint review, you can get feedback from your stakeholders/customers and refine your backlog accordingly.
Suggestions derived from my personal experience:
● Invite the stakeholders to the review and enable them to experience. Do not reduce your review into a powerpoint. Instead, let them use the increment.
● Let them talk and get feedback. Then, use those feedbacks to refine your product backlog.
● Clearly and transparently communicate with your stakeholder. Make emphasis on what you as a scrum team expect from them to achieve the product goal. Make them aware of the fact that this is a team work.
● After review, send out questionnaires and have them evaluate the sprint. By doing so, you can get the opportunity for improvement.
Sprint Retrospective
Scrum master is the responsible to hold the retro session and crucial for increasing effectiveness and quality. It is the session that team takes time to evaluate how things went with regard to increment, processes, interactions, and so on.
After retro, team comes up with possible solutions to the problems they encountered during the sprint. Or they decide to continue what is proved to be successful. They can also express their expectation from each other to ensure the effectiveness.
Retro is the last event of the sprint and usually lasts for 1,5 hours for a 2-week sprint.
Suggestions derived from my personal experience:
● Involvement is the most important thing during retro. Scrum master should encourage each team member to express their ideas and suggestions.
● After retro, if the possible solutions is discussed and determined, make sure to apply them for the next sprint. This increases the trust in the process and effectiveness.
Hope you enjoy reading it. Please feel free to share your experience and leave your comments below.
