Agile 101

Project Management, Digital Publishing and Agile Software Development

Archive for the ‘Scrum Meetings’ Category

Scrum Meeting Schedule – Two-Week Sprint

Posted by Tara Hamilton-Whitaker on July 24, 2009

meeting-scheduleSo, 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 Meeting:

Sprint planning is split into two parts.

  1. The first part is attended by the full team 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.
  2. 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:

  1. What have I done since the last Scrum,
  2. What am I going to do today (does this impact anyone else?)
  3. 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 Planning Poker Card 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:

  1. What went well last sprint?
  2. What didn’t go so well last sprint?
  3. 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.

Related Articles:

Advertisements

Posted in Project Management, Scrum Meetings | Tagged: , , , , | 3 Comments »

Scrum Sprint Planning Meetings – Who, What, When, Where, Why

Posted by Tara Hamilton-Whitaker on July 24, 2009

Credit: thegoldguys.blogspot.com

Credit: thegoldguys.blogspot.com

Sprint planning should take place on the first day of the sprint. This session is divided into two parts, the first part is attended by the delivery team and the product manager, whereas the second part is usually only attended by the delivery team.

The session can take place anywhere, however due to the collaborative nature of the session, it’s probably best if there’s a big table that everyone can fit around.

Attendees:

  • Scrum Team
  • Product Manager
  • Relevant Product Owner(s) – (optional – only if they are required to explain a requirement)

Tools/Documentation:

Agenda:

  1. Presentation of the product backlog by the Product Manager (Team/Product Manager)
  2. Team and Product Manager define Sprint Goals (Team/Product Manager)
  3. ****BREAK****
  4. Agree upon User Stories to be delivered in the coming sprint (Team)
  5. Agree delivery strategy (Create task cards for each User Story) (Team)

Presentation of the product backlog by the Product Manager

This session kicks off with the Product Manager presenting each backlog item to the team in priority order. These backlog items should be in User Story format and should be accompanied by relevant acceptance criteria and Test Confirmations where possible.

Most of these items will already be familiar to the team – they will have been introduced to them at the Scrum Requirements Workshop.

Some of the stories will have had outstanding actions/questions that were raised at the Scrum Requirements Workshop – these will all be addressed within this session.

The team should advise the product manager on the number of stories to go through in this session – it’s usually good to have at least 1.5 sprints worth of stories ready at any given point in time. The team may feel particularly ambitious one sprint, or disruptions may force them to accept new stories into a sprint – better to be prepared.

The team and Product Manager may enter into negotiation in this session – they’ll seek to clarify expectations, priorities and the level of investment required in any particular story e.g. ‘do you want me to go all out on that story or do you want something basic?’. If the scope changes entirely, the team may re-estimate a story using their Planning Poker cards.

Once the team are clear on the expectations, they move on to the next agenda point.

Team and Product Manager define Sprint Goals

Sprint goals are actually really useful – we didn’t start creating them until quite recently. Although it may not be an obvious side-effect of setting goals, I find teams actually become quite creative at this point. They begin to look outside of the pre-defined User Stories and might make a few suggestions on other things that can be done to better fulfill the sprint goal.

Nevertheless, this discussion ends with a few goals having been defined. Try not to commit to more than 3 or 4 goals. This keeps things focused. These goals will be used to benchmark the success of the sprint at the Sprint Review Meeting – did they meet their goals?

Once the team are fully-briefed and aware of their goals, the Product Manager usually leaves the team to it.

Team agree upon user stories to be delivered in the coming sprint

Once the Product Manager leaves, the team reflects upon the objectives and discussion. They then look through the prioritised backlog and agree the slice that will be taken forward into the next sprint.

Before making a commitment, the team will review the following:

  • How many Story Points did they deliver last sprint
  • Are there any holidays planned for the coming sprint
  • Are there any big milestones/events taking place that may affect their velocity

Once the team agree on the number of stories to accept, they will begin to plan their delivery strategy.

Team agree delivery strategy

It is at this point that some teams break the User Stories down into tasks, which are then estimated in hours. If the User Stories are small enough, it may not be necessary to break them down further. The approach taken will affect the way the team tracks progress during the sprint.

Burning down on Hours or Points?

If tasks are estimated in hours then teams will generally burn down on hours remaining at the end of each day e.g. Joe starts a 6 hour task, at the end of day one he has 2 hours remaining on the task so the burn down chart reflects a 4 hours decrease in ‘hours remaining’.

If User Stories are small enough, then the teams will generally burn down Story Points upon completion. e.g. Joe starts a 5 point task and finishes it after two days. At that point he adjusts the burn down chart to show a 5 point decrease in ‘points remaining’.

It is also at this point that the team may need to draw ideas on a whiteboard/make notes on task cards etc.

Note:

This session will take longer if:

  • The team is less established
  • The project is new
  • The sprints are longer
  • The User Stories are not clearly defined in advance of the session
  • The User Stories are too big***
  • People deviate from the agenda^^

***Although it shouldn’t translate, I’ve met a lot of Product Managers and Agile Teams who all seem to agree that all sprint contenders should be estimated at 13 points and below. Stories above 13 points will often be less thought through.

^^ Each team is different. Some are good at sticking to the agenda, others are less good. Agree your meeting rules in advance of the session – some teams come up with interesting ways to control one another e.g. raising a ‘Time Out’ card when people go Off Topic.

Reblog this post [with Zemanta]

Posted in Project Management, Scrum Meetings | Tagged: , , , | Leave a Comment »