Scrum and the phases of the SDLC model

The phases of our SDLC model that are important to the development effort happening during specific parts of a Scrum process are as follows:

• Before development starts:
  • Requirement analysis and definition happens during the story creation and grooming portions of the process, often with some follow-up during Sprint planning. The goal is for each story's requirements to be known and available before the story is included in a Sprint.
  • System architecture and design items follow much the same pattern, though it's possible for a story in an iteration to have architecture and/or design tasks too.
• The development process itself:
  • Development, obviously, happens during the Sprint.
  • Quality assurance activities generally also happen as part of the Sprint, being applied to each story as it's deemed complete by the developers. If testing activities reveal issues, the story would go back to an In-Development status, or perhaps an earlier status, on the task board, and would be picked up and corrected as soon as possible.
  • System integration and testing will probably happen during the Sprint as well, assuming that an environment is available to execute these activities with the new code.
  • Acceptance can happen on a story-by-story basis as each story makes its way through all the QA and System Integration and Testing activities, or it can happen all at once at an end-of-Sprint demo-and-acceptance meeting.

It's not hard to see why Scrum is popular—from a developer's perspective, with disciplined planning and devoting care and attention to making sure that the developers' time is respected and realistically allocated, their day-to-day concerns reduce down to whatever they're working on at the moment. Given a mature team, who have a reasonably consistent skill set and a good working knowledge of the system and its code base, Scrum will be reasonably predictable from a business perspective. Finally, Scrum, if managed with care and discipline, is self-correcting—as issues or concerns arise, with the process, or with the system and code base to some extent, the process will provide mechanisms for addressing and correcting those items.