For every lab that we undertake, we implement an agile regime to provide a working structure for the team. The below is an example of a structure that we have implemented before.
The regime document we put in place includes an overview of the process along with definitions as we use them. Also included are meeting agendas and any expectations of the team.
There are a number of variables such as sprint duration and the digital project management tools which are used (E.g. Trello or RealTimeBoard). In the below example we have been using RealTimeBoard to replicate a physical wall layout in our office space.
Agile Regime Example
Summary
| Sprint Duration | 2 Weeks |
| Sprint Planning | 1st Monday of the sprint @ 0930, in the office |
| Sprint Review & Retrospective | 2nd Thursday of the sprint @ 1500, in the office |
| Stand Ups | Daily @ 0915, Virtual |
| Strategy Sessions | 1st Wednesday of month @ 1000, in the office |
Agile is an iterative and incremental process that works well for managing projects in situations of complexity where you don’t know what the final outcome will look like. It is well-suited to social labs for this reason. Agile encourages a process of continuous improvement (both to the process and to the product) through short bursts of activities (sprints) with plenty of time built in to review and reflect. This approach has its roots in software development. There are a few ‘agile’ methodologies, but the one we use is called “Scrum”.
Terminology
In a Scrum team there are three distinct roles:
Scrum Master
The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project’s key stakeholder, who is referred to as the product owner.
The ScrumMaster does anything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint. The ScrumMaster role is commonly filled by a former project manager or a technical team leader but can be anyone.
Product Owner
This person is a champion for the product*. They are responsible for bridging the gaps between the client, stakeholders, and the Scrum team. The product owner is an expert on the product and the client’s needs and priorities and will help clarify project requirements.
Product owners make the decisions about what the product does and does not include. As well as the responsibility of deciding what to release to the market and when.
*”Product” In this context can refer to the Project overall.
Team Member
The Scrum Team are the people who create the product. Facilitators, researchers, designers etc. Anyone who has a hands-on role in developing the end result. High-performing scrum teams are highly collaborative; they are also self-organizing. The team members doing the work have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks, and how long those tasks are supposed to take.
The Backlog
The cumulative list of desired deliverables. This includes stories, process deliverables, documentation, and anything else that might be meaningful and valuable to produce.
The Sprint
This is the time period that the team will work on certain tasks from the backlog. Sprints typically last 1 or 2 weeks, for this example we’re using a 2-week sprint duration.
The Sprint Backlog
The sprint backlog is the team’s to do list for the sprint. Unlike the product backlog, it has a finite life-span: the length of the current sprint. It includes: all the stories that the team has committed to delivering this sprint and their associated tasks. Stories are deliverables, and can be thought of as units of value. Tasks are things that must be done, in order to deliver the stories, and so tasks can be thought of as units of work. A story is something a team delivers; a task is a bit of work that a person does. Each story will normally require many tasks.
RealTimeBoard
RealTimeBoard will be used as a project management tool. This allows us to replicate our physical wall space layout easily in a digital format allowing us to communicate with remote members of the team.
Sprint Meetings
Sprint Planning Session
Takes place at the beginning of each sprint. The goal of the planning session is to emerge with a set of “committed” stories that the whole team believes they can deliver by the end of the sprint. The product owner leads this part of the meeting.
One by one, in priority order, the product owner presents the stories he would like the team to complete during this sprint. As each story is presented, the team members discuss it with the product owner and review acceptance criteria to make sure they have a common understanding of what is expected. Then the team members decide if they can commit to delivering that story by the end of the sprint. This process repeats for each story, until the team feels that they can’t commit to any more work. Note the separation in authority: the product owner decides which stories will be considered, but the team members doing the actual work are the ones who decide how much work they can take on.
Next, the team rolls up its sleeves and begins to decompose the selected stories into tasks. Stories are deliverables: things that stakeholders, users, and customers want. In order to deliver a story, team members will have to complete tasks. Task are things like: get additional input from users; design a new screen; add new columns to the database; do black-box testing of the new feature; write help text; get the menu items translated for our target locales; run the release scripts.
The product owner should be available during this half of the meeting to answer questions. The team may also need to adjust the list of stories it is committing to, as during the process of identifying tasks the team members may realize that they have signed up for too many or too few stories.
The output of the sprint planning meeting is the sprint backlog, the list of all the committed stories, with their associated tasks. The product owner agrees not to ask for additional stories during the sprint, unless the team specifically asks for more. The product owner also commits to being available to answer questions about the stories, negotiate their scope, and provide product guidance until the stories are acceptable and can be considered done.
Review
At the end of each sprint, all Team members are invited into a meeting to review what has been completed in that sprint. It’s an hour long meeting, and allows the team to discuss what they’ve done. It is not an opportunity to discuss whether tasks have been completed, that must take place before this meeting (it should be clear from the daily stand ups whether tasks have been completed or not).
Retrospective
At the end of the review there should be time for a process retrospective – The retrospective, held at the very end of each and every sprint, is dedicated time for the team to focus on what was learned during the sprint, and how that learning can be applied to make some improvement. We recommend one hour of retrospective time for each week of development.
Unlike the traditional “post mortem,” the aim of a process retrospective is never to generate a long laundry list of things that went well and things that went wrong, but to identify no more than one or two strategic changes to make in the next sprint. It’s about process improvement.
Daily Stand Up
A daily meeting with all team members to check in and ask/answer the following questions:
- Which stories [from the backlog] I’ve been working on since the last daily stand up.
- Which stories [from the backlog] I expect to work on by the next daily stand up.
- Any obstacles which are slowing me down.
This meeting will be held standing up (literally) at the beginning of the day, to encourage brevity. Includes a very brief check in (30 secs per person). Check-in questions – How are you doing? Is there anything affecting you right now that we need to know (e.g. didn’t sleep, had a family argument, had a great workout and am feeling energized etc.…). Should not take more than 15 minutes.
Monthly Strategy Session
The monthly strategy session is an open meeting for the whole team to review and discuss Lab strategy and get clear on overall priorities.
Epics vs Stories vs Tasks
A common question is the distinction of what makes a story in Scrum, and the level of detail needed to be included in a project management tool. There are three levels:
Epics
- Big, too big to deliver in a single sprint
- Will span multiple sprints
- ‘high level’. We often use the language of “workstream”
Stories
- Span a single sprint. If a story is too big to be delivered in a single sprint, then break it out into smaller stories.
- Stories can be thought of as the minimal amount of value deliverable by one or two people in a single sprint
- Made up of multiple ‘tasks’
Tasks
- Very tactical and detailed. E.g. “send an email to Tracy to check date for meeting.”
In terms of how this relates to RealTimeBoard:
What is useful for the rest of the team to know?
Stories are useful for the wider team (E.g. X is going to finalise the dates for the first lab workshop) but the tasks not so much (E.g. X is going to email venue to check date availability).
Epics, Stories & Tasks in RealTimeBoard
Epics & Stories are inputted as cards into RealTimeBoard. Epics are top level cards which will span multiple sprints – usually following the “workstream” format; Stories are nested underneath Epics. Tasks are often too detailed and create a lot of clutter, so are generally not added.
Due to time constraints with the process, epics and stories will be inputted into RealTimeBoard during the Sprint Planning meetings.
Process Summary
Below is the overview for the processes that we will be using:
Ground Rules
Ground rules are a list of behaviors and rules a team decide are useful for working together as a team in a productive and respectful way. AKA working agreements.
Ground rules don’t come about after having a big meeting to create them. They usually evolve over time and with the team. Most of the time a rule is added to the list when the team solves a problem and decides to do things in a certain way.
Very often new ground rules come out of retrospectives. For example a team might have encountered issues with some members making decisions on their own and after a discussion about how to avoid this in the future they decide to add the ground rule “We make decisions together” to the list of rules.
A team’s ground rules are specific and unique to each individual team. As they are a product of a team’s history, context and experiences no two teams’ ground rules will be the same.
Be aware that ground rules will change over time: New rules will be added and obsolete ones will be removed. Make sure to keep the rules a living list and to re-factor them once in a while. Below are some example ground rules to get started. These can be refined over time.
Ground Rules
- Always have a meeting agenda
- Each sprint must have a goal
- Never say “no” to stories, put it in the backlog and prioritize it later
- Be on time for meetings
- Be specific about your requests for feedback. Who needs to do what, and by when?
- All stories must have a clear description/Definition of “done”
- All stories must be assigned to a person/people
- Stories may be added to the current sprint as they arise; it’s not always possible to brainstorm every story during the planning session. Epics aren’t generally added mid-sprint.
- If it is VITAL that an epic is added to the current sprint then bring the team together to discuss and agree on prioritization.
- Delay with your story? Communicate it to the team as soon as you know it will be delayed – Do this through a comment on that story card.
- RealTimeBoard must be kept up to date – If you are working on a story, it should be reflected on RealTimeBoard. This means that if you find yourself working on something not in RealTimeBoard, then you need to add it in. This also means you need to make sure the stories are put in the correct row. We don’t want to spend the review session figuring out what has and hasn’t been done, it’s a waste of the teams’ limited time together.
Agenda, Sprint Planning, R&R Meeting
Sprint Planning Overview
The sprint planning meeting has two main outcomes:
- A sprint goal; a short, one- or two-sentence, description of what the team plans to achieve during the sprint.
- A sprint backlog; a list of stories that that team commits to complete in order to meet that goal.
Sprint Review + Retrospective Overview
At the end of each sprint, a sprint review meeting is held. During this meeting, the team shows what they accomplished during the sprint. In a software environment this takes the form of a demo of the new features – Using this approach in labs, it’s an opportunity to talk through the stories you have completed and solicit feedback on them. It’s not a place to sign off on things that have been completed – The definition of done should be clear from the planning meeting, and stories should be moved to the Done row in RealTimeBoard in advance of the meeting. I.e. it should be clear to the team what has been completed already from the RealTimeBoard board. The review segment will be concluded by determining the top 3 priorities for the following sprint.
The retrospective is held after the review meeting. It’s a chance for the team to pause and reflect on how they could improve for the next sprint. There are numerous methods for running a retrospective (+EBI, 4Ls, etc.…). See here for more ideas: http://retrospectivewiki.org/
Preparation Requirements – Sprint R&R
Prior to the sessions some preparation is required from all team members. Allow 30 mins prior to the session to prepare for it – The prep outlined below will ensure that the session is efficient, but also engaging for all participants:
- All cards in RealTimeBoard must be updated on the board. If a card is complete, make sure it is in ‘done’ on the board. This allows the team to spend time during the review session to show off what they’ve completed, rather than assessing whether something has been completed.
- Each team member should have ready some things to present to the team around what they have completed that sprint. The intention is to make for an engaging review session where team members get to see each other’s’ work and find out more/ask questions about it. Allow 15 mins prior to the session to prep your materials (e.g. document links ready to share, or tabs open ready to screen share etc.)
- Spend 5-10 minutes thinking about the process that week. What has worked for you? What hasn’t?
Preparation Requirements – Sprint Planning
Prior to the planning session some preparation is required from all team members. Spend 10-15 minutes in advance of the session thinking about what you want/need to be working on that sprint. Write these down in preparation for the planning session to allow it to run more efficiently.
Agenda for Sprint Planning Meeting
Agenda for R&R Meeting
Daily Stand Ups
Each day the team will have a daily stand up in order to check in with each other and clarify any support needs. This will take place at 0915 each day. It’ll take a maximum of 15 minutes and team members will answer the following questions:
- What have I been working on since yesterday?
- What am I working on today?
- What do I need help with/What blockers am I facing?
Please set the intention of joining the stand up each day and try to avoid scheduling other meetings at that time. Obviously sometimes it is unavoidable (e.g. when doing delivery, or if a client can only do a meeting at that time etc.), in which case please send an update to the team in particular to anyone who you need help/support from.
Wall Layout Format
Story Post-Its
Agile Resources
Below are some links to learn more about agile:
https://www.agilelearninglabs.com/resources/scrum-introduction/
https://www.atlassian.com/agile/scrum
https://www.mountaingoatsoftware.com/agile