Velocity
The performance of a team is measured by the stories the team completed in the last Sprint.
This performance is called “Velocity”.
When working with Story Points we can calculate this velocity by summing up all Story Points of completed Stories.
Otherwise we just take the number of Stories. Of course this is less accurate because there are always bigger stories and smaller stories.
Sprint Goal
The Sprint Goal is one sentence – like a vision for the Sprint.
It is written by the Product Owner and needs to be accepted by the team.
During a Sprint there are no changes allowed that affect the goal of a Sprint.
Release Plan
I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Release Planning Meeting
I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
SCRUM process
The SCRUM Process is like this for each Sprint:
- Sprint Planning Meeting
- Sprint with Daily SCRUM Meetings
- Sprint Review Meeting
- Sprint Retrospective Meeting
Definition of Done
To complete an item from the Product Backlog or an Product Increment it is important that there is a common understanding of what “Done” means within the project team.
Only when you defined what “Done” means, you can find out if work on an item or on the whole Product Increment is complete or not.
The definition od “Done” guides the Development Team in understanding how many items of the Product Backlog they can accomplish during a Sprint.
For achieving a high quality it is useful that the definitions of “Done” contain stringent criteria.
Acceptance Criteria
Acceptance Criteria are written in simple language, easy to understand – just like a User Story.
In the Sprint Review Meeting the Development Team demonstrate the functionality for all User Stories the have worked on to the Product Owner by showing how each Acceptance Criterion is fulfilled.
Acceptance Criteria belong to a User Story. This has several benefits:
- they make the Developement Team look through the user’s perspective
- they make requirements clear and concrete
- they indicate the tests that will confirm that a feature / a piece of functionality is working correctly and complete
Example
- The user can only send the form, when all mandatory fields are filled out.
- All information send by the form is stored in the database.
- Protection against spam must be given.
- The page loading time may not increase.
- The user must enter a valid credit card information.
- The user will receive a confirmation email after submitting the form.
Sprint
A Sprint is a 1-4 weeks timeboxed iteration of a product.
In a Sprint end date and deliverable to not change.
The purpose of each Sprint is to deliver an Product Increment of releasable functionality.
Details
A Sprint can be cancelled by the Product Owner, if the goal of the Sprint is obsolete now.
Story Points
Story Points are units to measure the complexity of a User Story.
It does not equal the time needed to complete the story.
This fact is important to ensure that the number of Story Points does not depend on the experience of the developer who will accomplish the story.
To define the Story Points of a User Story you can have a look on its characteristics/complecity, e.g.:
- number of layers affected in the architecture
- number of interactions needed (with designers, front-end developers, …)
The best thing is always to complare it to previous User Stories with a similar complexity and then define the Story Points.