Scrum Meeting Schedule – Two-Week Sprint
So, you’ve heard about Agile and Scrum, your company is sold into the benefits, you’ve had your Scrum Master training, you’re good to go… and now you need to set up all of the meetings!
This post will give you a simple overview of the Scrum Meetings and some suggestions for how you might like to schedule/run them.
I’ll base this post on a two-week sprint as this seems to be the most common within the Digital Publishing industry. The agendas and the logic behind the scheduling order remain the same regardless of the sprint duration, however the length of time invested in meetings will vary (it should always be kept to a minimum – no more than 10% of the sprint effort).
Day 1 of the Sprint
Sprint planning is split into two parts.
- The first part is attended by the full team Product Owner and the Product Manager – this is when the product owner presents the highest priority backlog items to the team – there is a Q&A to ensure that requirements are understood. The team and Product Owner then agree on a number of sprint Objectives.
- The second part of the session is usually only attended by the team. It is in this session that the team discuss the requirements, make their sprint commitments and agree a delivery strategy.
Read more about the Scrum Sprint Planning Meeting – agenda, attendees, documentation/tools and tips (agile101)
Day 2 of the Sprint
Daily Scrum
This stand-up meeting lasts for no more than 15 minutes and is attended by the sprint team i.e. anyone that is directly involved in delivering the sprint commitment. We also invite relevant stakeholder and the Product Manager to these meetings (but they’re not allowed to say anything!).
This session is for the team – for them to update one another and to raise awareness about issues that might prevent them from achieving their combined sprint goals.
Each team member answers the three Daily Scrum Questions:
- What have I done since the last Scrum,
- What am I going to do today (does this impact anyone else?)
- Is there anything blocking you (or likely to block you) from delivering to plan?
The Scrum should be held in front of the team Task Board (or Epic Board) and an up-to-date Burndown Chart should be on the board for all to see. Any conversations deviating from the above questions should be held after the Scrum.
Read more about The Daily Scrum (mountaingoatsoftware.com)
Day 3 of the Sprint
Daily Scrum
Day 4 of the Sprint
Daily Scrum
Day 5 of the Sprint
Daily Scrum
Day 6 of the Sprint
Daily Scrum
Day 7 of the Sprint
Daily Scrum
Requirements Workshop
This session is lead by the Product Manager and is attended by the Team. In some instances, it may also be appropriate to invite business sponsors/product owners to this session.
The objectives of this meeting are to discuss any new requirements or changes to existing requirements that have emerged since the previous session.
This session will highlight any initial concerns/questions regarding contenders for the following sprint. This is also a good opportunity to assign T-shirt sizes to backlog items so to get a sense of size – this will help the Product Manager to determine priority/scheduling.
The Product Manager has time in between this session and the effort estimation session to amend the backlog/stories, get answers to questions and feed back to Product Owner(s).
Day 8 of the Sprint
Daily Scrum
Planning Poker
This session is attended by the full team and the Product Manager. The Product Manager turns up with a prioritised Product Backlog – a good rule of thumb is to have enough stories scoped to fill 130% of the sprint (base this on t-shirt-sizes).
The Product Manager presents each User Story to the team, answers any outstanding questions raised in the Requirements Workshop, and then sits back as each member of the team votes (at the same time) on the level of effort required to deliver the User Story. This voting is done by each team member revealing their chosen in unison at the count of ‘three’.
The highest and lowest estimates will be discussed in front of the team (why so high? why so low? ) If consensus can not be reached, agree to take an average or agree to re-visit the User Story at the Sprint Planning Session. The team can use the time in between this session and Sprint Planning to investigate any open questions before committing to an estimate.
Day 9 of the Sprint
Daily Scrum
Day 10 of the Sprint
Daily Scrum
Sprint Review
This session is attended by the team, the Product Manager and maybe even the Product Owner(s). The point of this session is to demonstrate the sprint deliverables and to assess the performance of the team against the pre-agreed sprint goals.
Due to the level of collaboration and consultation taking place between the Product Manager and Team during the course of the sprint, this is unlikely to be an ‘unveiling ceremony’ – there should be no surprises. Note that only accepted User Stories are counted towards the team velocity for that sprint.
Retrospective
The retrospective is attended by the team – the Product Owner and key stakeholders may also attend but this is discretionary (I’d recommend getting the Product Owner involved here if possible). Retrospectives as are all about reviewing mistakes/inefficiencies and agreeing ways to make things better. They’re based around three (main) questions:
- What went well last sprint?
- What didn’t go so well last sprint?
- What are we going to do differently next sprint?
I can’t stress how useful these sessions can be if facilitated properly. I’ll write more about retrospectives soon.
It’s worth noting that this schedule will vary from team-to-team e.g. some choose to have the Requirements Workshop and Planning Poker on the same day with an hour in between so people can quickly investigate unanswered questions. There’s no ‘right’ or ‘wrong’ way – have a go and see what works best for you.
Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!
Related Articles:
I actually was able in my SDLC processes to marry the Waterfall with Scrum and Agile and it is working ...
I experienced that using story points based on complexity has brought the team disagreement in assigning points. We still ...
Hi, in addition to your article, you can view this list as well on my website in a more clear ...
Good article, and I STRONGLY ENCOURAGE everyone to read Andy Bruce's earlier response. Andy has nailed the often missed point ...
You have completely demonstrated the whole scheme of software development within the above diagram on such a fine way. Truly ...
I’m curious about the scheduling of the requirements workshop and planning poker session on day 7 and 8.
I’m currently also using 2 week sprints, but I’m sure the team would consider the timing of those meetings highly disruptive to the last days of the sprint. Basically the last 3 days before the review would probably not be particularly productive. Not only the interruptions of the meeting, but the fact that those meetings take the focus away from the work in the current sprint.
Hi Rick – Great point. Truth is that each of our teams does this slightly differently e.g. some hold the meetings on day 6/7 whilst others do both on day 6, 7 or 8. Each team ends up deciding their own schedule – if it’s not working, they talk about it in their retrospective.
In our experience, the first three days and the last two days are generally the most intense for the entire team – product manager included. By having the requirements workshop on day 7, the Product manager has four semi-solid days to gauge sprint progress, review the backlog, prepare new stories, meet with stakeholders etc.
As the team becomes more established, requirements workshops become shorter on average – some teams only meet for 30 minutes to discuss new stories. With that said, as long as the team decides on a schedule and sticks to it then the disruption will become factored into their velocity.
Hope that makes sense.
Tara
Hello Guys,
Thank you very much for the fantastic article.
I’m just curious about the Testing activities during the sprint and wondering how you guys manage it. I’m part of the test automation team following Agile.
My question is when should a Test team start preparing the test resources like – Testcases, test scripts etc
As in this case if its a 2 week sprint, and if we assume we are (Test team) getting a new build/release from development team, ideally the test team should have the test cases handy so that they can test the requirements OR system. Also ideally when should we start automating the test cases?
Please clarify.
Thanks
Vinod
I just found this site. As I read through articles, I find a lot of usefull and interesting information.
I see nobody answered vinodkris’ question. I have an interest in the answer too. Would you please respond to it?
Thanks.