This post presents a practical guide of what happens during a typical Agile iteration – a sort of play-by-play for each role in the team, day by day. Please open the attached spreadsheet which models the day-by-day activities of a 2-week Agile development iteration, and describes the main activities for each role during this 10-day cycle of work. In addition, we will highlight how to successfully string iterations together, without any dead time; as the success of any given iteration is driven by preparation that has to take place in earlier iterations.
This is intended as a guide, rather than a prescription. While each iteration will have its own pace – a successful release will follow a sequence not too different from the one presented here.
Golden Rules
Each company is different, each project is different, each team is different, each release is different, and each interpretation of Agile is different. The following states the immutable principles to which I personally adhere.
- Once Engineering and Product Owner agree on the deliverables of an iteration, they are frozen for this iteration
- Engineering must deliver on time
- Features cannot be changed, added, or re-prioritized
- Only exception is a “customer down” escalation of a day or more
- Engineering delivers “almost shippable” quality code at the end of the iteration
- Each release is self-contained: all the activities pertaining to a given user story must be completed within the iteration, or explicitly slated for another iteration at the start of the iteration
- E.g.: QA, unit tests, code reviews, design documentation, update to build & deployment tools, etc
- Dev & QA engineers scope their individual tasks at the beginning of each iteration. The scope and deliverables of the iteration are based on these estimates.
- Engineers are accountable to meet their own estimates
The above implies that Engineers must plan realistically by
(a) accounting for all activities that will need to take place for this iteration, and
(b) accounting for typical levels of interruptions and activities not specifically related to the project (scheduled meetings, questions from support, beer bashes, vacations, etc).
Estimates must be made with the expectation that we are all accountable to meeting them. This sounds like a truism, except that it is rarely applied in practice.
Day by Day
Before the Start of an Iteration
Preparation and planning prior to an iteration are critical to its success. As the spreadsheet highlights, the Product Manager spends the majority of his/her time during a given iteration planning the next iteration, by
(a) Prioritizing the tasks to be delivered in the next iteration
(b) Documenting the user stories to the level of detail required by developers
(c) Reviewing scope with Project Manager and Tech Lead
Pre-requisites at the Start of a Release
The following must be delivered to Engineering at the start of a release. The Product Owner, Project Lead and Tech lead are responsible for providing
- “A” list of user stories to be implemented during the release
- Detailed specs of the “A” list user stories
- Design of the “A” list features sufficient to derive the coding and QA tasks necessary to implement the features
- Estimated scope for each feature – rolling up to a target completion date for the iteration
These estimates are “budgetary”. Final estimates are given by the individual engineers.
Day 1 – Kick-Off
The whole team gets together and kicks-off the iteration: the PM presents the “A” list features to Eng, and the Tech Lead presents the critical design elements. Tasks are assigned tentatively.
During the rest of the day, engineers review the specs of their individual tasks, with the assistance of PM and Tech Lead. This results in tasks entered into Jira, with associated scope and individual plans for the iteration.
The Project Lead combines all tasks into a project plan (using artifacts of his/her choice) to ensure that the sum of all activities adds up to a timely delivery of the iteration. The Project Lead also identifies any critical dependency, internal and external, that may impact the project.
A delivery date is computed from the individual estimates, and the team (lead by Product Owner, assisted by Project Manager and Tech Lead) iterates to adjust tasks and date
Day 2 – Deliverables are Finalized
Day 1 activities continue if necessary – resulting into a committed list of deliverables and a committed delivery date
The team, lead by Project Manager, also agrees on how the various tasks will be sequenced to optimize use of resources, and to front-load deliverables to QA as much as possible.
Developers start coding, QA engineers start writing test cases and/or writing automation tests
Day 6 – V1 Spec of the Next Iteration
By Day 6, the Product Manager provides the V1 Spec of the next iteration.
V1 Spec is a complete spec of all the user stories that the Product Owner estimates can be delivered in the next iteration. Typically, V1 will contain more than can be delivered, in order to provide flexibility in case some user stories are more complex than originally thought to implement.
During the remainder of the release, the Tech Lead (primarily) will work with the Product Owner to flesh out the details of the next release, to design the key components of the next release to a degree sufficient to be able to (a) list out the tasks required to implement the user stories, (b) estimate their scope, and (c) ensure that enough details has been provided for developers and QA engineers.
During the discussions of the next release, the Project Lead will identify any additional resources that will need to be procured, whether human or physical.
Day 7 – Release to QA
Release to QA means more than “feature complete”. It means feature complete and tested to the best of the developers’ knowledge and ability (see below).
Day 9 – Code Freeze
By Day 9, all bugs must have been fixed, so that the QA team can spend the last day of the iteration running full regression tests (ideally automated) and ensuring that all new features still work properly in the final build
By that time, the content and scope of the next release has been firmed up by Product Owner, Tech lead, and Project Manager, and task are tentative assigned to individual engineers.
Day 10 – Show & Tell
At the end of the last day of the iteration, Eng demos all the new features to the PM, the CEO and everyone in the company we can enroll.
We then celebrate.
Tools and Tips
Sequencing Iterations
- Depending on the complexity of the user stories, the Tech Lead (and other developers) may need to spend all of their time doing design, and may not be able to contribute any code.
- It is sometimes more productive to write automation tests once a given feature is stable. As a consequence, the QA team may adopt a cycle where they test manually during the current iteration and then automate the tests during the next iteration (once the code is stable)
- Exceptions to “almost shippable” are things like performance and stress testing, full browser compatibility testing, etc.
- These tasks are then planned in the context of the overall release, and allocated to specific iterations
Release Duration
The duration of a given iteration is at the discretion of the team. It is strongly recommended that iterations last between 2 and 4 weeks. It is also recommended that the duration of iteration be driven by its contents, in order to meet the Golden Rules. There is nothing wrong with a 12- or a 17-day iteration.
Start on Wednesday
Similarly, the starting day of the iteration is up to the team. Starting on a Wednesday offers several advantages:
- The iteration does not start on a Monday -). Mondays are often taken up by company & team meetings.
- Iteration finishes on a Tuesday rather than a Friday. Should the iteration slip by a day or two, it can be completed on Wednesday, or Thursday if need be. This means that the QA team is not always “stuck” having to work weekends in order to meet the deadline, nor do they have to scramble to make sure that developers are available during the weekend to fix their bugs, as would be the case if the iteration started on Monday
- By the second weekend of the iteration, the team will have good enough visibility into its progress, and determine whether work during the weekend will be required in order to meet the schedule.
Specs
The artifacts, format and level of details through which specs are delivered to Engineering is a matter of mutual agreement between Product Owner and Engineering, recognizing that Engineering is the consumer of the specs. As such, it is Engineering who determines the adequacy of the information provided (since Engineering cannot create a good product from incomplete specs).
Specs must be targeted for QA as well as Dev. In particular, they must be prescriptive enough so that validation tests can be derived from them. For example they may include UI mockups, flow charts, information flow diagrams, error handling behavior, platforms supported, performance and scaling requirements, as necessary.
Release to QA
While the QA team has the primary responsibility of executing the tests that will validate quality, developers own the quality of the software (since they are the ones writing the software). As a consequence, when developers release to QA, they must have tested their code to ensure that no bugs of Severity 1 or 2 will be found by QA (or customers) – unless they explicitly agree in advance with the QA team that certain categories of tests will be run by QA.
Regardless of who runs the tests, the “release to QA” milestone is only reached when enough code introspection and testing has been performed to warrant confidence that no Severity 1 or 2 bugs will be found.
Releasing to QA
Developers and QA can agree on how code will be released to QA. While the spreadsheet shows one Releate to QA milestone, this was done for clarity of presentation. In practice, it is recommended that developers release to QA as often as possible. Again, this should be driven by mutual agreement.
Furthermore, each developer must demonstrate to his/her QA colleague that the code works properly before the code is considered to be released. This demo is accompanied by a knowledge transfer session, where the developer highlights any known limitations in the code, areas that should be tested with particular scrutiny, etc.
Estimating Scope Accurately
One of the typical debates is whether time estimates should be measured in “ideal time” (no interruptions, distractions, meetings), or “actual time” (in order to account for the typical non-project-related activities). This is a matter of personal preference – what counts is that everyone in the team uses the same system.
I prefer to use “Ideal time”: each engineer keeps 2 “books” within an iteration: the actual iteration work – scoped in “ideal time”, and a “Other Activities” book, where all non-project-related activities are accounted for. This presents the advantages of (a) using a non-varying unit to measure the scope of tasks so that you can compare across people, project, time, and (b) having a means to track “non-productive time” on your project – and thus have data on which to drive decisions (e.g. pleading management for less meetings)