Sprints and Sprint Planning
A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. For our team, we use sprints in conjunction with Open UP phases. This means every phase of the Open UP (inception, elaboration, construction, and transition) is composed of a set number of sprints. Within each phase we have designated goals which we accomplish through the sprints. Below is a visual overview of the Open UP process.
Within these project phases, the team will work on an iterative cycle of 2 week sprints. The goal of a sprint is to completely finish an increment of the project with visible changes being made to the system. This allows the stakeholders to continually monitor the progress of the team and communicate any comments. Before the end of each sprint, we set aside three days to ensure our features pass verification and validation checks. This allows us to troubleshoot any issues before the Demo meetings at the end of the sprint.
A user story captures a software feature from an end-user perspective. It describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement and breakdown work taken on in a sprint. This is often tracked using a software management tool like Trello.
The following image captures an example and template of how to create user stories:
Role - The user should be an actual human who interacts with the system
Action - The behavior of the system should be written as an action
Benefit - The benefit should be a real-world result that is non-functional or external to the system
Another rule of thumb is to use INVEST acronym when writing user stories
Independent: Should be self-contained in a way that allows them to be released without depending on one another.
Negotiable: Only capture the essence of user's need, leaving room for conversation. User story should not be written like contract.
Valuable: Delivers value to end user.
Estimable: User stories have to able to be estimated so it can be properly prioritized and fit into sprints.
Small: A user story is a small chunk of work that allows it to be completed in about 3 to 4 days.
Testable: A user story has to be confirmed via pre-written acceptance criteria.
User stories should be identified together with the stakeholders, preferably through a face-to-face meeting. User story is a requirement discovery process instead of an upfront requirement analysis process. Begin by sitting down with the stakeholder and taking notes on what they envision the system to have, and any constraints. This will help to create preliminary stories which can be further refined.
After creating a story, one must discuss with the product owner definition of done through Acceptance Test. This is how the customer or product owner will confirm that the story has been implemented to their satisfaction. Think of this as a checklist of items that must pass in order for a story to be considered complete.
It should follow the following format: Given/When/Then. See example below
Product Backlog
Through the communication between user and project team, user stories are found. At this state, the user stories have nothing more than a short description of user's need
Sprint Backlog
Through a discussion between different stakeholders, the user stories to be addressed in the next few weeks are decided. This is the stage where the team develops well defined acceptance criteria.
In Progress
During this state, the story is actively being developed.
Testing
Once the story passes all the acceptance criteria, the developers will write up tests and verify the feature associated with the user story card is ready for production.
Completed
Finally, the feature is confirmed to be done, the user story is considered in the completed state. If the product owner wants to make adjustments, a new story may be created.
(Being one sprint ahead)