Iteration
The iteration is the heart of agile development as it gives structure to team planning. I'll be guiding you through how to setup and manage your team's iterations with an example structure.
Although some may argue that there is a difference between an iteration and a sprint, know that they are both generally used in the industry as a term for a (usually) 1-2 week continually repeated timeframe in which a team scopes, locks in, then accomplishes tasks. The iteration is punctuated with a planning meeting to start the iteration and to close out the previous iteration and is sprinkled with very short check-in (Standup) meetings. We use a task board to keep track of progress and prioritize tasks during an iteration. Finally, we track long-term trends in the iteration to improve our efficiency.
If you want to see how the iteration fits into the bigger picture of the product pipeline, you should read my article about it.
When putting together your agile development plan, I like to start by defining the iteration as it plays a central role. I'll walk you through the aspects that you and your team should consider when planning your iteration as well as all the other agile development tools and methods. Although all my suggestions are generally what I think is most ideal, you should consider your business's and team's needs.
Choose your tools
Some might find it backwards to start with the tools rather than the methods, but you'd be surprised at how many compromises you'll need to make based on the tools you use. Since the tools are the least flexible aspect of the process, let's start there and work around it. You can certainly try out different tools, and I would recommend doing so before finalizing any decisions.
Can I do this old school with pen and paper?
A lot of Agile teams choose to only use physical tools instead of software/apps (e.g. using sticky notes and a whiteboard for your task board). I don't recommend this approach, specifically because it doesn't support remote work or distributed teams. That said, the reason why the Agile community likes physical materials is that it keeps the methods pure and focused on fulfilling the right purpose. Don't let the bells and whistles of software tools distract from the real reason you're using them.
Project management
The biggest choice you'll need to make is your project management tool. I recommend using Trello or GitHub Projects (beta). I chose Trello as an example because it's no-frills clean, simple, and free (to start with). I chose GitHub Projects as an example because that's what we use at PocketRN. The project management tool will help you keep track of tasks, who they're assigned to, and their current status, as well as which iteration the tasks will fall on.
What about Jira? Or {{ insert name of tool here}}?
Jira is a great tool for turning agile development into a bureaucratic nightmare. Don't get me wrong; it's the most common and powerful project management tool out there. But with great power comes great amount-of-superficial-features-that-management-abuses-turning-the-benefits-of-agile-development-into-a-redtaped-gridlock-of-omg-I-just-want-to-create-a-#!$&ing-ticket!
More seriously, there are a ton of tools out there that can be used. I recommend any that are specifically built to benefit your engineers rather than your managers or your other business units. If a tool has features (dashboards, reports, metrics, etc.) that can be used to shame an engineer into working harder, don't use that tool. We chose GitHub Projects specifically because only engineers have GitHub accounts.
Team meetings
Iteration planning and execution require several different types of meetings. Some of these meetings are very quick and casual (Standup) and can be done easily in person or over a video conferencing call. Some, however, require you to be huddled around your project management tool. If your office has dedicated rooms for projecting from your laptop, then that's fine. If not, I highly recommend that these meetings be done virtually over a video conference call so one person can screen share and others can follow along. These are generally good meetings for team members to bring their laptops so they can update the tasks, shift things around, and demonstrate code changes as you go along.
We use Zoom at PocketRN for all our meetings, but you should use whatever your company permits by default.
Velocity tracking
Some project management tools will have designated velocity tracking; however, I tend to find them to be focused on the wrong metrics, to be overly complicated, or to be underwhelming. Instead, I recommend just keeping track of your team's velocity on Google Sheets or Excel 360. Either way, all team members should have access to collaborate on this sheet.
Issue submission
You'll also need some way for other teams (specifically, the customer support team) and potential customers to submit user feedback, bug/issue reports, and feature requests.
I recommend keeping feedback and feature requests as separate processes as there should be other gatekeepers for properly organizing and prioritizing non-urgent tasks (which I outline in my product pipeline article).
Client bugs/issues should however have a straightforward documented process for getting to the responsible engineering team. This ensures fast triaging and cycle times. You could utilize your project management tool for pulse filing, but there's a benefit to limiting access to the tool from outside teams (like the support team). At PocketRN, we keep it simple by having a designated public Slack channel (our communication tool of choice) for each engineering team that anyone can submit a verbose, templated summary of the issue. The on-call engineer for that team then reviews and catalogs the issue inside their team's project management tool as a new task, linking it back to the issue itself.
You just glazed over the entire support ticketing process
Yes, I did. Sorry about that. It's just a bit out of the scope of the agile development process. For those interested though, your support team really should have a designated "Help Desk Ticketing System" (Google it) for keeping track of customer pulses and the progress made on escalating, resolving, and reporting back to the customer about the resolution of said pulses. I wish I had a recommendation for you, but I'm only moderately familiar with Zendesk and no others. It's just not my area of expertise. 😢
Define your iteration
Should my team have a 1 or 2-week iteration?
I've done both. For partially or fully remote teams, I highly recommend 1-week iterations with minimal other iteration meetings. I've found that team members may often grind against a problem unnecessarily long when working remotely because it takes more effort to validate with another teammate than when they are sitting next to you.
For same-office teams, I recommend a 2-week iteration as you can spread the weekly meetings, giving your engineers more time for deep work.
Establish meetings
You'll want to determine which meetings you want for your iteration so you can get them as recurring meetings on everyone's calendar. There are several possible iteration meetings. I recommend two and a half of them. The fewer meetings you have, the more time you give back to your engineers (which you should be very conscious of).
Iteration planning
At the start of every iteration, your team will need to meet around your task board to review the work done in the last iteration and the planned work for this upcoming iteration. Generally, the meeting should be about 10 minutes per team member (e.g. a 5 member team would have a 50-minute meeting), but you should also provide some buffer time in case greater discussion is needed on specific tasks.
The meeting should be very hands-on. Go through the task board, update and move tasks, and assign out to individuals. For meaty discussions that you know will take time, schedule them to be discussed in another meeting and only invite the members that are impacted.
We'll dive into the details of this meeting later on.
Stand up
Daily, typically at the very start of your team's workday, you should have a very quick standup meeting (it's coined a standup because traditionally you have the meeting while standing, but please remain in your seats if you're having it virtually; no one wants to see that you're wearing sweat pants). The meeting should be about 2 minutes per team member (e.g. a 5 member team would hold a 10-minute meeting). Using a standardized order (e.g. alphabetical), every member should say:
What they accomplished yesterday.
What they plan to accomplish today.
Any blockers or items that need the team's attention.
One-sentence answers are totally acceptable. The content should only be on the aspects of the iteration that you are tracking. Members shouldn't say things like, "I had a lot of meetings yesterday." or, "I had this frustrating conversation with one of our customers." If the content is not relevant to the greater team, there's no need to mention it. Remember, like all of agile development, this is not a check-in to ensure you're doing work. This is a check-in to ensure you can do your work and tackle anything that may be stopping you.
Demo days (the ½ meeting)
Lastly, I recommend that you have–at very specific intervals–a meeting to demo the progress the team has made. Normally, this is part of an iteration retrospect or review meeting at the end of every iteration (which I discourage because it's just too many meetings). Instead, I recommend that before every release you have a "demo day" meeting (or if you run fully continuous deployment then at major release milestones).
The meeting should be ad hoc and take as much time as you think your engineers need in aggregate to demonstrate the work they've fulfilled, typically about 10-20 minutes per engineer. We personally leave the meeting open for anyone in the organization to join if they'd like, such as other engineering teams or the product manager. The meeting shouldn't be dumbed down for a wider audience: keep it as technical and low-level as needed.
These meetings are a great way for your engineers to proudly demonstrate their efforts, especially if those efforts are not customer-facing. It's also a great way for the rest of the business to keep tabs on engineering efforts.
Choose your verbiage
There's a lot of lingo around an iteration. Your engineers will be coming from different companies that use different terms, so you should accept that you will not be able to police the jargon; however, you should at least define what terms you favor using. Some terms we haven't covered yet, but we will shortly. Here are a few such keywords that you'll want to settle on:
| Option A (what I use) | Option B |
|---|---|
Iteration | Sprint |
Stand up | Daily huddle |
Iteration planning | Sprint planning |
Task board | Kanban |
Dev Day | Story point |
User Story | Milestone |
Next Steps
That's about as much as I can cover without diving into templates and examples using our project management tools of choice. The next pages will be more hands-on and technical, and you may want to have your tooling selected and follow along as we dive into these topics.
Last updated