Agile in Detail

Have you ever felt like there was too much to work on?  Has your team ever been distracted from accomplishing work because there are simply too many things to work on?  Has it ever been hard to focus on just one thing?  Have you ever found it hard to give up on an idea that isn't working, and try something new?

It’s almost certain that your team can answer “yes” to all of the above questions.  It’s normal.  Robots are very complex, and there are a lot of tasks.  Defining and managing that work is hard, and often the “right” answer requires a certain amount of work just to get headed in the correct direction.  What we need is a development process that will help us focus our activities and get stuff done.

What we need is Agile Development.

What is Agile Development?

The core idea of agile development is that large projects are very hard to plan, and that people work and plan better when they can break a problem down into smaller pieces.  Additionally, as humans we are always learning, so the best practice is to use knowledge we gain to continuously improve what we work on as well as the development process itself.  Agile puts a framework around those ideas and helps to make project management easier.  

Agile is a popular form of "Continuous Development", where work on a project is not thought of as having a definite end, but rather as a continual process of improvement.

In order to explain Agile, there are three core concepts we need to understand.

Core Concept #1 - Tasks & Spikes

In Agile development, all work that you will be doing is to be written down and tracked as either a task or a spike.  The difference between the two is whether or not you know what work you need to accomplish (a task), or if you need to do some investigation first (a spike).  Knowing the difference between the two is a key part to the Agile process.  

Let’s use that as an example for the development of a robotic gripper.  When a team comes up with an idea, it will probably not be clear what the best way to construct that idea will be.  In that case, you will start with a spike (or perhaps a set of spikes).  For example, you might have a spike to investigate options for how the gripper will be built.  You might also have a spike to investigate how to control the gripper in code.  Then you time block those spikes - for example, you might give 4 hours to each spike.  The goal of that work is to investigate options and to learn. Once the spike is done, the only thing you will have completed is learning about what needs to be done.  Everything you build during the spike should be thrown away.  Yes… that’s right.  The ONLY thing you get from a spike is knowledge.  

Once you've finished your spikes, you should now be ready to define tasks to build the gripper.  Because your spike tasks helped you understand how to build a gripper, you can now define the exact work necessary to build a really good gripper.  Once those tasks are defined, you will estimate the amount of work needed to complete the tasks.  Ultimately, then once those tasks are complete, you now will have a very well designed, well built, and well documented gripper.

Core Concept #2 - Sprints

Another key concept in Agile is the concept of a sprint.  A sprint is nothing more than a short period of time where you will plan and perform your work.  Typically a sprint will be defined to last two weeks - usually this is long enough to get a fair amount of work completed, but short enough that you can accurately plan what should be accomplished.

During a sprint, you will be working on sprints and tasks.  Here’s the key thing … whatever you’re working on, ONLY WORK ON THAT THING.  Keep focused on what you’re trying to accomplish. If you’re working on a task to build a gripper, work on that task alone.  Do not try to jump around between tasks because that will take away from your focus and keep you from finishing what needs to be done.

Core Concept #3 - The Review Process

Finally, at the end of each sprint, you will review what work was accomplished in the sprint.  Ideally all tasks and sprints planned for the sprint were “closed” (meaning completed).  You MUST set aside time at the end of the sprint to review what got accomplished and review how the process is going.  Then be prepared to discuss what is going well, and what is not going well.  Then take action: make improvements to the process so that next sprint it runs smoother.

Big Picture

Let’s now back up a step and put these concepts together.  As we said before, the core idea in Agile is the concept of a sprint.  A sprint represents the amount of work the team is actively working on, and usually sprints are 2 weeks in duration.  It's an important point that the ONLY work being done by the team is work that was "pulled in" to the sprint.  Any work not in the current sprint (for whatever reason) will be handled in a later sprint and should not distract from current activities.

Here's a normal set of sprint cycle meetings.  I'm assuming a two week sprint with a total of 4 meetings, though of course this could easily be adjusted.  We've found that a 2 week sprint cycle works fairly well - it's small enough to plan effectively, but not so small that sprint planning takes over.

Meeting 1

  1. Sprint Planning (first thing, typically 10-30 minutes)
    1. The main objective of sprint planning is to set the work to be accomplished during the sprint
    2. Address any items from the previous Sprint Retrospective 
    3. Review the progress toward the Epics
    4. Write down the Stories to be done during the sprint - team members choose and write these
      1. Team gives a rough estimate of how long it will take to do the story.  This is hard a first, but you will get better at it
      2. Note that a story may come up that doesn't fit in this sprint… just save it for a later sprint
    5. Break down the Stories into Tasks or Spikes as much as possible, but without going into too much detail
      1. The team may not yet be able to determine all of the work necessary to finish a story… that's OK
    6. Assign the tasks and spikes to team members.  (often that happens as tasks/spikes are written)
  2. For the rest of the meeting, team members work on their various tasks/spikes

Meeting 2

  1. Scrum (first thing, 10 minutes max)
    1. Each team member discusses the following
      1. What I did last time
      2. What I intend to do today
      3. Is anything blocking my work
    2. Tasks/spikes/stories are crossed off if completed, and new added as necessary.
  2. Team members work on their various tasks/spikes

Meeting 3 (run the same as Meeting 2)

  1. Scrum (first thing, 10 minutes max)
  2. Team members work on their various tasks/spikes

Meeting 4

  1. Scrum (first thing, 10 minutes max) - same as meetings 2 and 3, but team should be reminded of the Sprint Review
  2. Team members work on their various tasks/spikes
  3. Sprint Review (toward the end - 20 minutes … adjust as necessary)
    1. Each person or group demonstrates what they accomplished during the sprint
      1. Focus should be on what was accomplished
      2. Each person demonstrates in some way … even showing a poster or talking about a decision that was made is demonstrating the work
    2. Note that each person should know about the Sprint Review and plan to be ready ahead of time.  
  4. Sprint Retrospective (at the end - 20 minutes … adjust as necessary)
    1. Each person answers two questions, and this is written down for the group
      1. What went well?
      2. What can be improved?
    2. The team should discuss what changes (if any) they would like to make to make the process work better.  

Now repeat

Next meeting will start a new sprint.  So… go back to Meeting 1 and begin the cycle again.  Remember that the goal of each sprint is to help you focus on what can be planned and accomplished in that two week period.  

The Details

OK, so there are clearly a lot of terms here.  Finally, we’ll offer definitions for each.


Epics are the high level goals that the team is trying to accomplish.  An Epic might be something like "Build a Robot to Compete In This Years Challenge", or "Produce an Outstanding Project".  Epics are the things that will take a long time to complete.  The exact path to completing an Epic is not planned in great detail (yes, this is hard not to do!) - rather the Epic serves as a guidepost to make sure that the team is working toward a common set of goals.


A Story is an amount of work that will be accomplished during a sprint, and is specific to progressing to finish a particular Epic.  It's important that stories not be too big - they need to be small enough that they can be completed in a single sprint.  A story might be "Complete xx mission", or "Improve xx mission to run in 20 seconds", or "Write and perform the project skit"


A task is an actual piece of work to accomplish a story. Task sizing it a bit of an art… they should be small, but not so small that you spend a lot of time managing the writing down and crossing off of tasks.  A task might be "Set up line following to get to xx point", or "Improve the bulldozer attachment to do xxx", or "Write the first draft of the skit


Sometimes the team doesn't know how to accomplish something, or maybe even how to estimate how long it will take. When that happens then it's time for a spike.  A spike is work that is intended as a learning experience only.  All of the work that is done can (and often is) thrown away or taken apart.  The point of a spike is for team members to learn enough so that they can then write the tasks and estimate how long it will take to complete a story.

Spikes might be the most important and yet the hardest part to get correct.  Spikes typically don't last very long, and the idea is to do enough work so that the problem or solution is clarified in some way. One outcome of a spike is "well, that way didn't work", which might lead to another spike to try a different approach. A spike should end, and task(s) begin, when it becomes clear that the idea being investigated will work.

Note… one possible outcome of a spike is that the story we had originally written is wrong. It might be that the team members figure out that the story they thought would make sense just doesn't. That's OK as well, just go back and adjust the story as necessary.

Sprint Planning

A single meeting at the beginning of a sprint where the sprint is planned.  Team members should start by reviewing how the process has been going and progress that is being make to finishing the Epics.  As you go along, you will also want to discuss how this sprint will be different from the last sprint, especially if you're adjusting based on the last retrospective


This is the core … the thing you do at the beginning of every meeting.  Usually team members stand during this meeting - it helps focus and get everyone to give quick updates  The purpose of the scrum if for each team member to take ownership of what they will be working on.  Progress is updated only.  New tasks/spikes are written, tasks/spikes/stories are crossed off by team members outside of the scrum time (though it's OK to update during the scrum as well)

Sprint Review

This is Demo Time!  Team members show what they've been working on.  Each team member demos to everyone else, and only positive comments are allowed.  The idea is to have each member be aware of everything that has been accomplished, and where the team is overall.

Sprint Retrospective

Each team member is asked two questions: (1) What went well? and (2) What could be improved?  The leaders then work with the team to decide if any changes should be made.  So, for example, a team member might say that the organization of Lego parts it making it hard to build … so an outcome might be to rearrange the parts to make things work better.  Another example might be that we got all of our scrums done within the first 10 minutes of each meeting, so an outcome might be that we want to keep that up!  

There's a key thing here - Agile development allows for flexibility in the process. Anything can be changed … what's important is that the team gets to a process that works well for them.

In Summary

Agile development is a powerful form of continuous development, and has been very successful for many teams at various levels of FIRST robotics.  By applying this methodology to your team, you too will have success.  Just remember that you cannot “short cut” the process.  There’s no half way; if you’re going to do agile development, you must do it all.  You must do sprints, you must break your work down to spikes and tasks, and you MUST do the sprint reviews and retrospectives.  It’s the combination of all of these things that leads to a successful outcome.