AGL Academy

Need help?

Sprints are a strong foundation to the iterative Agile process.

In order to practice running an Agile project, your team will need to practice a project on a very small scale. It’s critical that your team executes all the features and follows this format:

Estimated Time

• Seven hours for the workshop (full team)
• 14 hours of preparation (Agile Project Manager)

Materials Needed

• Work room
• Workstations
• WiFi
• Demo mechanism
• Storyboard
• Post-Its or index cards, pens
• Timer

Outcome
A demo-able, functional prototype, and a shared confidence in the process.

---

Preparation

Sprint Structure
This is a model of the sprint structure that will be used for your future projects. It allows you to practice much of the Scrum ceremony within very compressed one or two hour sprints. As the Agile Project Manager, your job as a leader is to make sure that the Workshop happens and that you have a customer representative present. You may be the only person empowered to do this.

You may find it helpful to first read The Story Of An Agile Workshop and How A Two-Day Sprint Moved An Agency 20 Years Forward.

Stories Backlog
In the next workshop, you will be building a backlog of the stories that really matter to you. However, for the purpose of this workshop you may want to choose something in which your team is less emotionally invested.

A reasonable topic for this three-sprint project is to produce a resource website about an important subject. Far-reaching and well-known topics — like breast cancer or global warming — are rich, valuable, and provide ample opportunity for development. Almost all developers and/or development teams should be able to produce a website quickly. This project cycle allows for 4 hours of development total, so it will need to be a site that can be done in that amount of time.

Sprint Deadline
As the Agile Project Manager, you’re responsible for ensuring the process is followed and to make sure that time is strictly adhered to. In this kind of workshop you will be under tremendous pressure to extend a sprint deadline. You must not do this. When the time comes for the demo, the demo happens. If the developers have to say “We implemented zero stories in this sprint”, then they say that in front of the whole workshop and the demo is over and you go on to the next phase.

The Team
Part of the beauty of this style of workshop is that it puts developers in close communication with end-users. This communication should be fostered. Usually, this is where the magic happens. Nevertheless, there are some roles that must be respected. The workshop is formally divided into the development team and the “customer-facing” team. The customer-facing team includes the Product Owner, writers, and end users.

Member Rapport

• The development team does not question the priorities set by the customer-facing team.
• The customer-facing team does not question the estimates or mechanisms of the development team.

In other words, the customer-facing team may not say “I think that should be easier than X.” The development team may not say “I think this story is more important to our users.” The customer-facing team has absolute control of how stories are prioritized and whether a story passes or not at the time of demo. The development team has absolute control of the estimates and the technologies used. Note, however, that story writing is always a shared responsibility. The wording of the stories must always be produced in close collaboration.

Agile Project Manager Tasks

• Arrange one room large enough to fit all participants comfortably. This may require you to provide workstations, electricity, WiFi, or other telecommunications. Two rooms are not recommended.
• A technical mechanism must be provided for everyone to see the demo. Depending on the size of the team and the nature of the development, this might be just crowding around a laptop, using a projector, or having a separate machine dedicated to the demo. It could conceivably be done entirely by web conference if that is the nature of your application.
• Keep a storyboard – ideally a whiteboard broken into lanes showing the status of the stories. Make sure the stories move correctly forward on the storyboard so that it always reflects the status of all the stories.
• Ensure the workshop is always on schedule.
• Defend the rights of the team while fostering open communication. If a developer asks a question about a story, encourage the customer-facing team to answer it.
• If a customer-facing person asks a question about what is technically possible, refer this to the developers.
• Insist on everyone being present for the end-of-sprint demos as they are the climax and goal of the entire workshop.

Read

You must familiarize yourself with a few concepts that will be critical to running your workshop. A storyboard is a tool you will use to track stories throughout your sprints. Stories are assigned a point value based on the level of effort it takes to complete them. A burndown chart helps you express your team’s progress.

Learn about Storyboards ›

Learn about Story Value And Points ›

Learn about Burndown Charts ›

---

Workflow

Schedule
Now that your team  understands the tools, you are ready to begin the workshop. The format is critical because it is necessary to have all of the features of three full sprints compressed into a tight schedule. Each of the 3 sprints must end at a designated time and all workshop participants must be present for all demos. Do not postpone a demo. If your teams needs additional time for story writing, incorporate it into the beginning of a workshop. Otherwise, use stories from a previous workshop.

Refreshments
We strongly recommend providing refreshments to your workshop participants to help keep them focused. A three-Sprint workshop can be very strenuous and exhausting. If there is a large number of people (more than eight), consider recruiting an assistant.

Agenda
Remember that your job is to keep the workshop on schedule. In particular, each demo must be performed at the scheduled time. You are to foster communication between the developers and the rest of the team. It is not your job, or any one person’s job, to answer all of the questions. As the facilitator of the workshop, you should focus on the process, not the end result of what is actually developed. There must be a rigid agenda, with sprints One, Two, and Three beginning precisely at the planned time.

Workshop Structure

• An introduction and explanation of the process
• Sprint One
• Sprint Two
• Sprint Three
• Retrospective and reflection

Sprint Phases 

• Story writing: 10 min
• Story estimates: 10 min, 60 sec spent on each story
• Development: 80 min
• Demo: 10 min
• Sprint retrospective: 10 min
• Break: 15-30 min

Activities

Story writing
You should have stories already written from a previous workshop. If you choose to do a different project for this workshop it is recommended that you take time beforehand to write user stories, to prevent cutting into your workshop time. Use the time allotted for this first activity in the sprint to refine or add to the stories that have been created.

Story estimating
Although we prefer estimation in abstract “story points”, we recommend that you estimate in minutes for this one-day workshop. That means any story with an estimate of more than 45 minutes is too big, and must be simplified or split into several smaller stories.

You should spend no more than 60 seconds on estimating each story. If you already have your stories estimated from a previous workshop, then update story points to minutes and add estimates to any new stories. Ensure you are estimating in order of priority.

Development
Here is where your storyboard comes into action. Your user stories will have been prioritized by the Product Owner and your team will move the number of stories they think they can accomplish within the 80 minute development period into the “In Sprint” column. As the developer picks up a story it gets moved across the board. At the completion of each story, a developer should demo the story immediately to a customer-facing person. Try to get them to do this before the card moves to QA on the storyboard.

Demo
At the end of the development timebox, the developers will demo any cards that made it to QA. In a compressed timeframe, you may ask the crowd for a simple vote as to whether a story, after being demoed, should be considered passed or failed.

It is common for suggestions to be made during a demo, which might be considered either bugs or potential improvements. In a full sprint you may develop a policy for this. In a one-day workshop we recommend that you simply ask the non-developers (the customer-facing team members) for a voice vote on whether each story should pass or fail. There is no shame in failing a story. It simply moves back to the “In Dev” column.

It is best to create a burndown chart as a big, visible wall chart. With the completion of each demo, add up the estimates of all passed stories and immediately add it to the burndown chart. Executives and other observers generally love the burndown chart, as it easily quantifies the amount of work being accomplished.

Sprint Retrospective
The whole team discusses what worked, what didn’t work, and how the process can be improved in the next sprint. The Agile Project Manager can capture this input and help coach the team in the next sprint.

Break
Give the team a 15-30 minute break between sprints.

Assumptions

• Expect a fair amount of confusion and skepticism, especially at first. However, this will diminish as the team makes progress.
• There will be many, many questions that arise about each story. The workshop is forcing artificially fast story writing and very rapid estimation. Think of each story as a “promise to have a conversation”.
• Sometimes developers will need to work with concentration without being interrupted. This is not one of those times. Communication is key to this exercise. The end product is less important than the team learning the process.
• Velocity may be uneven. It is fairly common for a sprint to fail to complete a single story.
• By about the second sprint, the customer-facing people will be waiting on the development team while the developers are furiously working. The customer-facing people should use this time to make sure the backlog of prioritized stories is exactly what they want.
• Expect that after each demo, some learning will surface that causes the Product Owner to change his or her priorities. Expect demos to result in new stories being written.
• Expect about three-fourths, but not all, of the stories to be passed by QA.
• Expect everyone to be astounded by what is accomplished in this single day.

---

Guidelines

To some extent, it is a positive part of the process for things to go wrong, if the team can learn from the experience. Here are some common problems you may face:

• The team can fail to break the goal into small steps that can be executed within the limited time of one sprint, resulting in nothing to demo.
• Developers can impose their own desires on what gets built.
• Customers can fail to assert priorities.
• A team can be so large that it is difficult for them to coordinate work within a sprint. If that’s the case, break your participants into several smaller teams.
• The development team may devote too much energy to thinking about the final product and thus fail to do a good job presenting functionality in the first demo.

Quiz

• Did you accomplish three sprints, following all ceremonies?
• Do you have a functional prototype of something?
• Do you feel confident attempting 2-week sprints now that you’ve done three 2-hour sprints?
• Congratulations, you are ready for the last workshop!