Sprint Overview
Introduction
By now, your client project has evolved from a simple project proposal description into a more detailed design (aka charter) that is ready to start being iteratively built and deployed. Now that we are through Inception and kicking off the sprints we are ready to get into a weekly cadence of analyzing, designing, constructing, reviewing, and deploying the necessary items (e.g. system code, test cases, training, user/dev guides) to complete each sprint.
Each sprint can be divided up into two dimensions. You are already familiar with SDLC phases of a sprint but now we'll consider the functional vertical which may be tackled particular roles on the team. For the purposes of this overview, we'll discuss each SDLC phase within the sprint and break them out by Functions. See pictures below of how these apply to the PDM.
|
By SDLC phase: |
By Function: |
* - Project Management is clearly relevant too but it applies to all parts of the sprint regardless of function or SDLC Phase so it's not depicted in a specific area on the PDM.
Analysis
The purpose of the Analysis phase in the SDLC is to make take time to research any remaining unknowns about a user story or functional requirement and gain the necessary detail you will need to move forward with the design & build portions of the sprint.
- Development - Developers/BAs should be working as a development team to gather the remaining details they need to design and build the system. They should also be using this time to reconfirm the challenges to scope feasibility, call out any missed scope, and answer any open questions related to the chosen solution.
- QA - Someone (typically a Developer or BA) will need to be tasked with doing an inventory of all the functional requirements, features, and capabilities that are part of this sprint. This will be used to design a plan or outline of what needs to be tested so we know what test cases to construct.
- Change Management - Someone (typically a BA) will need to assess the client's skill set, system use, and training needs so they know what to design and build for guides and training.
Design
The purpose of the Design phase in the SDLC is to model and/or prototype the parts of the solution that may need to validation before moving into the construction phase. (e.g. ER Diagrams or Web Flows help you gather feedback before moving too far along into coding.) Taking the time to design before you code can prevent wasted time during build and test due to missing important design details.
- Development - The developer will need to create necessary models or prototypes that will serve them during the construction of the system and ensure they are building according to the client's needs and BA's vision.
- QA - Once the analysis is done to capture all requirements, features, and expected behaviors of the system, an overall list of components to test can be drafted. Also, we can design what test data is needed. During this time the person designing the testing should also consider negative tests (i.e. possible steps that could break the system code) and not just positive tests which check the system is behaving
- Change Management - Outlines or high-level designs of the guides and training materials are planned and designed here before the team dives into building out the final drafts of the materials.
Construct
The purpose of the Construction phase in the SDLC is to not only to build the system but build the things you need to test the system (e.g. test cases, test data) and prepare your clients for the change (i.e. training, user guides, developer guides)
- Development - The developer is tasked with building the system features of the current sprint and then doing their own detailed test of the code or configuration. After their individual or peer-develop testing is complete, they'll need to construct the developer guide or update the current version of it. Also during this phase, other teammates will be executing test cases and logging issues/bugs that will require the Developer to fixes so they can be retested before the sprint review phase.
- QA - The BA will be constructing test cases to validate that all critical features function as expected. Also, negative test cases should be constructed. All test cases will be stored in the Test Tracker provided to your team. During this phase, test data should be created and inserted into the system as needed. Before moving into the Review phase, test cases should be executed and the test tracker should be updated on whether the test passed or failed. If the test failed, it should be logged and steps to recreate the failed step should be sent to the Developer so they can fix it. After fixes are done, the BA should retest before moving to UAT (User Acceptance Test).
- Change Management - All materials needed for users (e.g. QRGs, Comprehensive Guides, Videos) and any training/communication materials needed for the sprint deployment are also constructed.
Review
The purpose of the Review phase in the SDLC is two-fold. 1) To internally review as a development team that what was constructed in the sprint (regardless if it's code, tests, or training guides) that they adhere to the design and is valuable to the client. 2) To have the client do their own test and review of the sprint's output so they can approve deployment or ask for a new iteration of changes before deployment.
- Development - The Developer should work with a peer developer or peer BA to review their code and system. They should also get feedback from their teammates on the developer guide. After the internal team reviews are complete the system and developer materials should be reviewed by the client and either approved or not.
- QA - Since the testing that is done by the development team really occurs in the Construction phase, this portion of the review phase focuses on the user's review of the sprint and their own testing.
- Change Management - The final user/developer materials and training should be reviewed by the client and either approved or not.
NOTE: If anything is not approved by the client, another iteration of analysis, design, construction, and review should occur for that area of work.
Deploy
The purpose of the Deploy phase in the SDLC is to deploy the code to its production environment or staging environment (i.e. an environment that multiple iterations of code are moved to before being moved to the final production environment). It is also to deploy training to users/developers and also communicate to key stakeholders that the updates of this sprint are not available.
- Development - Code or system changes are moved into the final environment and quickly retested by the developer and BA. Developers should make sure that the deploy is communicated to the client especially if it will cause a major change to the users or require downtime of the system.
- QA - By this point, all QA tasks should be complete BUT it's still necessary to run some quick tests of critical functions in production to make sure the sprint deploy works in production too as expected and that no changes caused other parts of production to break.
- Change Management - As part of the deployment of the spring, the team should be working with users and developers to ensure they are trained on the changes and know how to make use of the sprint's functionality and how to support it technically.
NOTE: When considering deployment, you have to consider two factors: Risk and Cost. Click here to learn how these two factors are impacted based on what type of deployment you pursue (e.g. Pilot, Immediate Cutover, Parallel, or Phased)
Post-Deployment
After your deployment of the sprint is successful, you should assess if there are more user stories in the backlog (i.e. Not Started). If there are, you will move back up to the top of the Sprint Execution on the PDM to start the activities of:
- Reevaluating risk - It's possible that risk has changed for the better or worse. Determine if you should change your risk reduction strategies or if you can close out some risks. Discuss your findings with the client.
- Reevaluating the schedule - Ideally, you have met the milestone of your recent sprint and are on track to start your next spring on schedule. If not, determine what the cause of the delay was and if a change to your overall project plan will need to occur. Discuss your findings with the client.
- Reconfirm the priorities of your next user stories - Using the feasibility/value matrix, determine if remaining user stories have changed in their value or feasibility. If so determine if the next sprint's user stories should be changed or remain as is. Discuss this with your client.