The sprint process is a popular way to implement the Agile approach to software development. Is has its detractors. However, there are many ways that this approach can split up a large project into smaller bites. This action of breaking something big into manageable pieces increases the chances of success. Also, a sprint helps us address numerous principles discussed in the Agile Manifesto.
Deliver Working Software
A challenging part of the sprint process is the goal of delivering working software as part of completing each sprint. We are not ignoring the SDLC steps. Those six steps are being repeated each sprint and require a little creative thinking.
Working software is not the same as useful. We can build a solution in a sprint that is light on the usefulness scale. For example, we can deliver software that allows a user to register and log in or a report with minimal data. These are both steps towards our ultimate solution, and working versions advance our overall progress. That makes them excellent ways to achieve a deliverable in a given sprint.
An SDLC Approach
The sprint process includes the common SDLC steps in each cycle. Maintenance may not appear very often. However, when you consider bugs fixes and similar backlog items as maintenance, you will see examples. We gather requirements by moving items from the backlog. A design period should be incorporated before implementation. Then we code and test. We wrap up by deploying the software and a customer review.
A Matter Of Timing
The SDLC steps are often done in a waterfall manner. Thus, we design, then implement, then test. That lays out a schedule where a little design is done in the beginning, a little testing at the end, and a lot of implementation in the middle. We need to adjust these tasks in a sprint to keep resources (dev team members) busy throughout the sprint process. This goal can be achieved with cross-trained members that can do the implementation and then switch gears to test the code of others. That allows heavy testing at the end by all dev team members.
However, team members have strengths and weaknesses. It is rare to find a developer that is also good at testing (or vice versa). Therefore, we want to utilize out testing resources early in the sprint process and not hold them ready until the final days. We can either solve this by implementing during one sprint and testing in the next or by completing items (ready to test) early in each sprint. Either way is feasible, but you will have challenges to work through in either case.
The Twelve Principles and Overall Manifesto
Challenge of The Week: Do you utilize the three sprint ceremonies?
