It’s a beautiful summer day and you go in to work halfway through the Sprint with a skip in your step and full optimism about finally having a great Sprint. The team has found its cadence and that critical feature being developed is making great progress. You walk in the door and hear the terrible news: John Pace (appropriately named star developer) had a bad burrito last night and has been puking his brains out. The User Story he was working on that delivers that key new feature, the crown jewel of the sprint, is not gonna happen. You sit on the floor and hold your head in your hands sobbing uncontrollably. You wonder why the universe hates you. You wonder how this could have been avoided….
Over the past 8 years of working on Agile Scrum projects in many different organizations, I have observed many different interpretations of Agile Scrum and have seen implementations of the Agile methodology with very widely varying degrees of success. In most cases, I have found teams ascribe strict ownership of a User Story to a specific developer and that developer is god of that User Story. But as in the scenario above, anything that happens to that developer could have a huge impact on that story and could leave the entire team scrambling to ramp up their knowledge and save that critical feature.
On a couple of very high -achieving teams, I have experienced a philosophy that seems to work: User Stories belong to the entire Development Team and not to any individual developer. While this may seem chaotic, it actually is pretty simple and logical. The entire team is responsible for delivering every User Story and there is no single point of failure. There are no heroes in this game. While you can assign User Stories to an individual, the execution of the story is a team effort and responsibility. Having this model work successfully depends heavily on good Scrum practice throughout the sprint.
Successful swarming is achievable when the Sprint Events are planned and executed with a goal of creating and maintaining a highly knowledgeable team that is truly capable of being self-organized. Developing this capability starts right from Backlog Refinement (Backlog Grooming) and right through the sprint execution and Sprint Review and Sprint Retrospective Events.
The Sprint Schedule
According to The Scrum Guide, the ideal size of a Development Team should be no larger than 9 members. I have found the sweet spot to be between 5 and 7 members. The benefits of this size of development team include:
- Easy communication between team members
- Quick daily Scrums. Smaller teams can achieve an effective daily scrum in well under 15 minutes
- Easier collaboration and knowledge sharing
- Fewer moving parts to keep track of
- Easier understanding of individual developers’ areas of strength
For teams of 5 to 7 developers, 2-week sprints have appeared to work out better than 3-week or 1-week sprints. The main benefits of 2-week sprints over 1-week or 3-week sprints have been:
- Long enough for a decent amount of work to be done without interruption but short enough for quick course correction where needed. 3-week Sprints do not offer as frequent opportunities for recalibration especially for new agile teams
- Administrative overhead is manageable. With 1-week Sprints, the overhead of the large Scrum events (Sprint Planning, Sprint Review and Sprint Retrospective) may be imprudent
- Shorter sprint events. Planning work for a 2-week sprint will take considerably less time than planning for a 3-week Sprint. The Sprint Review will also take considerably less time . With multiple scrum teams, this may be even more desirable as the number of scrum teams is a multiplier on how long the Sprint Review and Retrospective Takes
- Sprint Retrospective will capture much better quality information. It is harder to remember the details of a 3-week period of time than it is to remember the last 2 weeks so the feedback from team members will be more accurate and complete
It may seem like a great idea to start a Sprint on Monday and end it on the Friday of the following week. Link the sprints to the calendar week. Sadly, that is not necessarily the most efficient use of the development team’s time. In practice, I have found that Sprints that run from Wednesday to Tuesday (2-week sprints) offer a much higher level of efficiency and lots of opportunities for organization and planning. Consider the Sprint Schedule below:
- Wednesday 9am – Sprint Planning (2 hours)
- Wednesday (2nd week) 2pm – Backlog Refinement (1 hour)
- Tuesday 10am – Sprint Review (1 hour)
- Tuesday 11am – Sprint Retrospective (1 hour)
- Tuesday 1pm – Backlog refinement and Story Tasking (3 hours)
- Daily Scrum 9am – 15 minutes max
The main benefit of this schedule is that it gives the developers 2 weekends during the Sprint cycle where they can put in an extra push if required. This is extra time that is not planned into the sprint but can be extremely beneficial if unforeseen circumstances occur (like the recent Amazon S3 outage which completely halted development work at the organization I worked for at the time).
Why not have the Sprint review on Monday morning? Having the review on Tuesday morning allows the team to regroup and plan the review demo. It also allows for any last-minute integration tasks to be executed and for the Product increment be internally reviewed by the development team. The Sprint Review is a great marketing opportunity for the team as it will likely include product stakeholders and other attendees from outside the Scrum Team. It is therefore a great opportunity for the team to shine and it is important that the team shows itself in its best possible light. A little demo prep certainly helps for a smooth, high-quality demonstration of the work done during the sprint and can help garner enthusiasm and support for the development team.
Backlog Refinement – Spreading the knowledge
Have you ever been in a Sprint Planning meeting that drags on for hours and hours and even after that, there seems to be some confusion on exactly what the ask is from the Product Owner for the User Stories planned? How often do you have User Story estimates that are way off from the actual level of effort required to deliver the feature? Do you have developers often redoing work on a story because they didn’t fully understand it during Sprint Planning and what they built was not what the Product Owner asked for? These are all symptoms of a lack of Backlog Refinement (Grooming) and can lead to a lot of frustration and erode trust .
Backlog Refinement (or Backlog Grooming) is an activity that involves the Product Owner and the entire Development Team (not just the ‘leads’) where the Product Owner shares his vision and the business goals of the Product Backlog items with the Development Team and thereby gives them the opportunity to provide creative input and ask questions about the Product Owner’s wishes in those Backlog items. This prevents developers from going into the Sprint Planning blind and committing to work they don’t understand. Agile Scrum is about developing based on what you know right now and the Development Team commits to delivering a certain set of capabilities at the end of the Sprint. It is impossible to estimate work that you do not understand and it helps to have time to think about it. There is often not enough time during Sprint Planning to ask all the necessary questions but the Backlog Refinement meeting offers great opportunity to think creatively and ask questions.
The biggest benefit of the Backlog Refinement meeting (when it is actually a meeting with the Development Team and the Product Owner in the same room) is the amount of knowledge sharing that takes place. All team members are exposed to the wishes expressed in the Product Backlog items and the conversations around them also allow for an exchange of ideas on potential solutions and designs. Every developer should leave this meeting having some idea of an approach to solving the problems in the Product Backlog items they refined. The Product Owner also leaves the meeting with more information that will help refine the User Stories and their Acceptance Criteria.
Pre-planning – Story Tasking and light analysis
Having a few hours between the Sprint Review and Sprint Retrospective and Sprint Planning for the next Sprint can be very beneficial to the team. This downtime can be used effectively to refine the stories in the Product Backlog and perform some analysis and design around them. This work should be done as a group and will help foster even more knowledge sharing and cross-pollination of ideas across the team. The desired output from this meeting should be subtasks created on each story that reflects the work that would be done based on the team’s understanding of the asks in each User Story. Where possible, it may also help to provide hour estimates on the subtasks. It is much easier to estimate small pieces of work than the entire User Story and this approach allows the team to develop their strategy for tackling each User Story. This exercise often exposes risks or external dependencies that are not immediately obvious and could be helpful in the Sprint Planning .
Team-focused Sprint execution
A lot of organizations assign User Stories to specific developers going into Sprint Planning. The downfall of this approach is that developers become territorial about User Stories and essentially zone out of conversations around stories they are not assigned to. I have found that teams that do not pre-assign User Stories get a lot more team engagement during Sprint Planning. Then comes the concept of ‘Swarming’: each User Story belongs to the entire team and the entire Development Team is responsible for delivering it. During Sprint Planning, the entire team votes on the complexity of each user story using a predefined measure of complexity (t-shirt sizes or Fibonacci Numbers) and the entire team gives a vote of confidence on their ability to deliver each User Story in that Sprint. This activity is repeated for every User Story and Bug before it is added to the Sprint. If any developer has questions or has concerns about the ability of the team to deliver a particular User Story, that concern should be addressed and discussed until that developer has reached an acceptable level of confidence in the team’s ability to deliver the User Story in question. This is a Team commitment to each User Story rather than an individual’s commitment to each User Story.
Once the team feels like they have taken up enough work to confidently deliver in that Sprint, Sprint Planning ends. The developers should not be cajoled or coerced into taking on more User Stories in the Sprint than they feel comfortable with. Undelivered User Stories at the end of a Sprint can adversely affect team morale and can also affect trust and confidence within the Scrum Team.
Sprint Execution Strategy
Once Sprint Planning is over, it is very helpful to have a Development Team meeting to plan the Development Team’s strategy for executing the User Stories planned into the Sprint. Up to this point, nothing has been assigned to anyone. In this meeting, the team should identify the first one or two User Stories they will work on in the Sprint. Team members discuss their approach to working on each of the first two User Stories and split up the subtasks amongst themselves aiming to have an equal load distribution amongst the developers. For a typical user story, there’s typically enough work available for most members of the team to work on simultaneously. The Team should leave the other User Stories unassigned until one of the initial User Stories is completed and the Team is ready to take on a new User Story.
I recommend keeping the User Stories in progress to a maximum of two User Stories. The team should focus on closing out a User Story before starting a new one. There are of course exceptions to this but it helps to make the team focus on completing work rather than on starting work.
Life cycle of a User Story
While Agile allows for very quick development and embraces the philosophy of “code over documentation”, executing an Agile project is no excuse for poor engineering practices. Agile Scrum actually encourages solid engineering and quality-focused software development with the major difference that the engineering is done on small pieces of the product as you go rather than in one huge sweep in advance or after the fact. That means that the Software Development Life Cycle still lives on even in Agile projects, but on a Story-by-Story basis. One of the biggest mistakes I’ve seen tams make while implementing Agile projects is to skip the analysis and design stages and jump right into implementation. This is not the Agile Scrum way!
Agile Scrum encourages good analysis and design, solid testing and collaboration and high quality implementation of stable, maintainable and testable code.Agile Scrum is about building what you know for a reason you know and to meet needs that currently exist. To achieve this, the following sequence of tasks are important for almost every User Story:
- Acceptance Tests Definition – Meeting of all members of the team to understand the Acceptance Criteria and define a baseline functionality that once met, the User Story is done. This also helps clarify the scope of the story and helps avoid scope creep. The entire Development team should attend this meeting and it shouldn’t last longer than 30 minutes.
- Architecture Design – This is a very detailed conversation about the implementation of the story. This meeting should cover design considerations like API signatures, database designs, testing strategy, etc that’s pertinent to the various pieces being worked on. All developers should leave the meeting having a good idea of how the various pieces being built will integrate and more importantly, how those integrations will be tested from both a system and a user point of view. The developers should leave the meeting with draft BDD test cases
- Unit Tests and End-to-end Tests – Following the philosophy of Test Driven Development which is a critical part of Agile Scrum, the very next task after the Architecture Meeting should be tasks to write the tests. One developer (or pairs of developers if pair-programming) should tackle the unit tests and the End-to-end tests for the component pieces to be built based on the Architecture design
- Development tasks – Whatever tasks are required to build the feature and pass all the tests written
- Documentation tasks – “Code before documentation” does not mean “no documentation”. The team should take time to update any documents or write new documentation (e.g. API Documentation, READMEs) for the pieces worked on
- QA Testing – Even with all the automated testing available, manual testing and Quality Assurance is still critical to ensure the feature built meets the Acceptance Tests defined in the first meeting and does not introduce any new bugs not caught by the automated tests (e.g. broken stylesheets or missing images or icons or broken accessibility). One developer should be designated the QA tester for that User Story though all developers are responsible for the quality of the User Story.
- Code Reviews – All new or changed code must be reviewed against some predefined coding standards and best practices the team has agreed to.
Most teams jump right to implementing and skip the analysis, design and planning phases. it is important for Team efficiency and cohesion to perform the first 2 tasks as a team as this reduces the potential need for rework and makes the integration of the various pieces developed relatively seamless. While this may seem like a lot of extra work, it actually only delays implementation by about an hour and a half but with huge gains:
- Single point of failure is eliminated since the entire team is aware of the solution architecture
- It mitigates the risk of rework since the contracts between the various pieces are clearly defined
- It mitigates the risk of endless manual test cycles since developers go into implementation knowing how the feature will be tested
When the team swarms the User Stories in a Sprint, the story is completed more quickly and is more quickly available to the Product Owner for review in a development or staging environment. It is also more quickly available for any security or performance testing required and more time is available to fix issues found.
The Daily Scrum (or Standup) meeting is a great opportunity for developers to give a quick update on where they are with the work they’re doing and for the Product Owner to get visibility into how the Sprint is progressing. Contrary to what I’ve seen in a lot of projects, the Scrum Master is not critical to the Daily Scrum. When the Scrum Master attends the Daily Scrum, his/her role should be limited to guiding the team on executing the meeting. The Scrum Master is not a Project Manager and does not direct the team on what to work on.
The Daily Scrum should be as brief as possible and each developer should speak for themselves addressing the following three topics:
- What I achieved yesterday
- What I plan to achieve today
- What blockers / challenges are hindering my ability to deliver on my commitments
Developers should try to highlight achievements and commit to achievements in the current day. Those achievements should be directly related to the User Stories being worked on in the Sprint. There should be no conversations around the updates given during Scrum and any conversations or discussions needed should be scheduled for a later meeting typically directly after the Daily Scrum. Developers should avoid giving updates on behalf of other developers who are present. Every developer should have their own voice and give their own updates.
Pair Program as Often As Possible
Pair programming may seem expensive but it actually saves a lot of time and resources in development teams. There old saying that “two heads are better than one” holds especially true in pair programming as the rate of solving problems eventually increases. The re is also the added benefit of instant peer review which reduces the amount of code reviews, refactoring and cycles required after the development is complete.
One huge benefit of Pair Programming is the exchange of knowledge and the elimination of single points of failure. The unforeseen absence of a team member will have little or no impact on the team’s ability to deliver work in progress and. The combination of knowledge and expertise from two individuals can also dramatically improve the quality of the code written while sharpening the skills of each individual developer. Imagine a scenario where a developer with tons of AngularJS experience but limited CSS experience pair programs with another developer with stacks of CSS3 and HTML5 experience but not as much AngularJS experience. The resulting code would feature both their strengths and would be overall much better than if either developer had worked alone.
Bees achieve amazing things when they work in a swarm. The ability to tap into the strength there is in numbers is a skill that requires actually using the numbers to full benefit. A Development Team that functions as individuals rather than as a team does not harness the benefits of having numbers. When teams swarm User Stories, there are much quicker turnaround times and features are available for review and testing much quicker than if you have individual developers work on stories. There is also often a steady, even rate of delivery across the entire sprint than with individual developers where you have a whole bunch of stories coming to completion around the same time and thereby greatly increasing the risk for integration issues and merge conflicts.
Overall, the key benefits of Swarms are:
- No single point of failure on any User Story
- Increased domain knowledge across the team
- Improved code quality through Pair Programming
- Quicker turnaround times on User Stories
- Quicker feedback on features from the Product Owner due to quicker turnaround times
- Reduced risk of integration issues and merge conflicts
- Strengthening of weaker individual skills leading to a more self-sufficient Development Team
- Improved communication and cohesion
- Increased adoption of coding standards and team best practices
- Reduced QA cycles
- Reduced Code Review cycles
- Reduced rework of feature components due to integration issues