ManagingProj Sprints
With an Agile approach you will divide the time between the start of your project and its delivery date into sprints of equal duration in which you'll be completing tasks. At the start of each sprint you and your team will review the backlog and choose the tasks that must be completed in the new sprint. If you complete all of these before the end of the sprint then you'll start new tasks, one-at-a-time, from your backlog to fill the remaining time.
Remember that the goal of a sprint is to develop and release a set of capabilities that users could theoretically use. This doesn't mean that the app will have all the necessary or requested features at the end of the first sprint. Rather, Sprints build on one another throughout the life of the project until all major features have been implemented. This is the core of the agile approach and allows the team to get useful feedback throughout the project rather than just at the final product release.
Dividing your project in this way and planning and executing in a progression allows the team to adapt to change and to start tasks at the optimal point in time when enough details are known to allow development to be both efficient and result in something that is relevant.
Sprints are application development cycles having a duration of one week each. The sprint length is fixed across the life of the project and a fixed number of user stories are assigned to each sprint. This is not to say that stories cannot be added to the sprint. Just that they can’t be added if doing so exceeds the capacity of the team to create, test, and deploy a working application by the end of the sprint. It is quite often the case that teams under estimate the number of stories that can be completed and have to add stories to fill out the remainder of the sprint.
As previously mentioned, sprints build upon one another. With each sprint, the usability and value of the product increases as features are added and refined. Even though sprints result in a deployable application, users may choose not to use it in production until it reaches a certain minimum threshold of feature and functionality. However, having a working application increment helps to demonstrate progress and solicit customer feedback at the end of each sprint.
At the start of each sprint the PM defines a goal for the sprint and identifies which stories need to be completed to achieve it. The Project Team selects stories from this pool, reviews them, and commits as a team to their completion. This includes considering both the individual and collective complexity of each story using story points. One outcome of the review may be that the goal needs to be decomposed across multiple sprints if it exceeds the capacity of the Development Team
The team also plans for how they will work together to complete the sprint. This may include discussions around risks and contingencies, test plans, etc. An option available to the Project Team is to pair members of the team to work on certain stories. For example, it may be advantageous for a frontend developer and a backend developer to pair with one another to ensure that API’s are well established.
During the course of a sprint the Project Team gathers daily for a 15-minute meeting to report progress and roadblocks. Meetings of this type are referred to as the Daily Scrum in the Scrum methodology. In Chingu Voyages they are referred to as the Sprint Standup Review and the Sprint Progress Review. Their purpose is for each member of the team to review what was accomplished towards the sprint goal since the last meeting, what is to be accomplished by the next meeting, and to identify any obstacles. The goal of this meeting is to make sure that there is transparency across the team to both successes and roadblocks.
These are not intended to be meetings where issues or problems are to be solved during the meeting, but to expose them to the entire team and for teammates to schedule time to work on them. This allows the proper resources to be brought to bear so the time of other teammates is not wasted. Desired behaviour on the part of the team is for individuals to volunteer to help rather than resources being explicitly assigned by the PM.
At the end of each sprint, a Code Review is conducted to walkthrough the working product and to merge it into the project's master branch. This meeting is an opportunity to get feedback on the state of the product, discuss issues and possible changes or new features, and to decide on what to do next.
The Sprint Retrospective is conducted by and for the Project Team to promote continuous improvement. It is the primary means the team uses to improve their work and to drive value not just for the customer, but also for themselves in the form of a more integrated and smoothly operating team.
This is an inward look by the team at how they performed during the last sprint and an opportunity to identify changes for the next sprint. This isn’t just about technology and tools, but also about procedures, interactions between people and roles, and successes and failures. The goal is to improve by implementing “midstream” corrections at the point they are needed.
