Some things are more art than science. And while software development is definitely a science, testing it has more than a few artistic aspects to the process. Dan Valderrama, QA Engineer at AndPlus, talks about the typical two-week sprint and how the company ensures a quality, shippable product at the end of it.
Why Two-Week Sprints?
We asked Dan why a two-week sprint specifically, and what criteria was used for determining the length of a sprint for a particular project. Here’s his reply:
“The sprint length is chosen based off of the required time to consistently produce a new piece of deliverable functionality. We feel that two-week iterations are usually a good fit for most projects, but in the past we have also used one-week or even three-week sprints.”
Dan also explained that two-week sprints work well because they usually strike a good balance between:
- Giving engineers enough time to produce deliverable pieces of functionality;
- Giving product owners and stakeholders enough free time to take care of their own work; and
- Still being able to frequently give suggestions during or after sprint reviews.
“Product owners and stakeholders have the difficult task of juggling their own normal work with being available to answer questions from the development team,” says Dan, “and giving feedback and two-week sprints usually give them ample time to take care of their normal responsibilities and then set aside a couple hours to review the progress of the project.”
Before the Sprint
Dan explained that before a sprint can begin the team performs extensive sprint planning. This includes reviewing backlog tickets and agreeing on the ones that can be completed during the sprint. A grooming meeting is also held before the sprint begins, during which the team reviews tickets to ensure the details are accurate, up to date and ready for development to start. Once these processes are complete, the team is ready for the sprint to begin.
During the Sprint
“During the sprint the team has daily stand-ups,” says Dan. “These are 15-minute meetings where each team member states what they did yesterday and what they will be doing today. The stand-ups continue until the end of the sprint, which is when the team comes together to do a sprint review.”
The review gives the team a chance to demo the new features added to the project during the sprint to any product owners and stakeholders who are available, he explains. “This gives the product owners and stakeholders an opportunity to review the changes and give feedback or suggest improvements.”
End of Sprint
After the sprint is over and the project completed, the team gets together and holds a retrospective meeting, says Dan. During the meeting, the team members speak openly about organizational concerns they may have and how to address them moving forward. With most projects, the new product package with the changes made during the sprint is ready to ship immediately after the sprint ends. “There are some projects where the deployment of the product is very complicated, though, and those require coordination among different teams,” says Dan. “In these cases, the product is usually shipped the day after the sprint ends.”
A Successful Sprint
As a veteran of many sprints, Dan says there isn’t anything unusual about a successful sprint. “Our goal is to be able to consistently perform successful sprints and then build upon the success of the prior sprint when moving forward,” he says. “That being said, the sprints that are most successful are usually the ones with a high level of communication and teamwork between the different actors in the project.”
Sprints are an important aspect of agile technology, which is now an accepted standard among development teams. You can read about our 10-day Google design sprint, which provides details of each day’s activities. At AndPlus our QA team is constantly testing and debugging the sprints to ensure we have well-defined goals that we know we can meet, and the customer is kept updated on our progress at all times.
