- Scrum (artifacts and sprint)
- Roles
- Events
- Artifacts
- Metrics
- Definition of Ready and Definition of Done
- Story points (Estimation)
- Board
- References
Scrum (artifacts and sprint)
- Improving teams is a basic principle of Scrum.
- Scrum is a framework that helps teams work together, and deliver product with highest possible value within bounded period.
- 3 importances at scrum
- Everyone knows what to do
- Control of artifacts (product backlog and sprint backlog) and defects
- Including changes when needed
- Idea, todo, doing, done
- Sprint: Scrum divides a project into iterations (called sprints) of fixed length (usually two to four weeks).
- Product Increment: Each sprint results in a potentially releasable/shippable product (called an increment).
- Product Backlog: The product owner manages a prioritized list of planned product items (called the product backlog). The product backlog evolves from sprint to sprint (called backlog refinement).
- Sprint Backlog: At the start of each sprint, the Scrum team selects a set of highest priority items (called the sprint backlog) from the product backlog. Since the Scrum team, not the product owner, selects the items to be realized within the sprint, the selection is referred to as being on the pull principle rather than the push principle.
- Definition of Done: To make sure that there is a potentially releasable product at each sprint’s end, the Scrum team discusses and defines appropriate criteria for sprint completion. The discussion deepens the team’s understanding of the backlog items and the product requirements.
- Time-boxing: Only those tasks, requirements, or features that the team expects to finish within the sprint are part of the sprint backlog. If the development team cannot finish a task within a sprint, the associated product features are removed from the sprint and the task is moved back into the product backlog. Time-boxing applies not only to tasks, but in other situations (e.g., enforcing meeting start and end times).
- Transparency: The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum. This makes the content and progress of the current sprint, including test results, visible to the team, management, and all interested parties. For example, the development team can show sprint status on a whiteboard.
Roles
Product owner, scrum master, development team
- Scrum Master: ensures that Scrum practices and rules are implemented and followed, and resolves any violations, resource issues, or other impediments that could prevent the team from following the practices and rules. This person is not the team lead, but a coach.
- Product Owner: represents the customer, and generates, maintains, and prioritizes the product backlog. This person is not the team lead.
- Development Team: develop and test the product, 3-9 people. The team is self-organized: There is no team lead, so the team makes the decisions. The team is also cross-functional. Everyone responsible for delivering product
Events
- Sprint = 2 weeks period of time, during which, some scope of work need to be done
- Grooming - capacity and velocity (define сложность и длительность задачи), use Planning poker
- Sprint planning - meeting in which scope of the work will be created
- Sprint backlog - tasks need to be done during sprint
- Daily scrum - daily meeting, where each member tells what they have done yesterday and what they will do today, and do they have any blockers
- What have you completed since the last meeting? What do you plan to complete by the next meeting? What is getting in your way?
- Sprint review - presenting new features by teams with description of what they do
- If can’t be show (tech work), they team should describe business value. For example during the sprit we have refactored the module, and it started working faster
- Retrospective - discussion after sprit, team discuss what was bad, good, and what can be changed, and SCRUM MASTER gets this info and tries to resolve in the next sprint
- What went well, what can we improve, action items
Artifacts
- Product backlog - features, user stories, tasks added by PO
- Event - product backlog refinement (уточнять все ли понятно по user story)
- Spring backlog - list of tasks to do during the sprint (should be done until finish)
- Product increment - The developed part of product and the part which being developed in current sprint and we can show in demo.
- Definition of ready and definition of done
- DoR - helps to customer to create the user stories that are ready to be developed
- DoD - helps to check that the work was done following all specification and requirements, not only demonstrating the functionality. For example, all integration tests passed, the ratio of critical bugs are 5 percent
- User story - As a … I want … so that. Acceptance criteria
- Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty. it is based on old sprints
Metrics
- Velocity (average number of story points the team able to finish during the sprint), capacity (available working hours of dev team)
- A burn-down chart shows the amount of work that has been completed in an epic or sprint, and the total work remaining. Burn-down charts are used to predict your team's likelihood of completing their work in the time available.
- Cumulative flow diagram is graph which shows how the tasks were moving over each level (idea, todo, active, done).
Definition of Ready and Definition of Done
These are useful tools for negotiating project scope as they define expectations and hold both parties accountable; the DoR helps the customer for producing well written user stories that are ready to be consumed by the Development Team, and the DoD helps the implementation partner for producing working product increments according to all project requirements, not just the specific user story functionality.
- Definition of ready covers the requirements coming into the sprint.
- A “ready” backlog item needs to be clear, feasible and testable:
- A user story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-priority ones facilitates clarity
- An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested
- A user story is feasible if it can be completed in one sprint, according to the Definition of Done. If this is not achievable, it needs be broken down further.
- Definition of done covers the product coming out of the sprint.
- The Definition of Done is an agreement between Development Team and the Product Owner on what needs to be completed for each user story.
- Documentation, feature tested, functional and non-functional requirements are meet, feature deployed.
‣
Story points (Estimation)
- Story points represent the complexity of a story in relation to its effort.
- Story points are a tool to determine the velocity of teams. Story points are a way of measuring the complexity of a story.
- Velocity of team = sum(story points) / number of sprints
- For instance, if the Scrum Team has finished a total of 80 points over 4 Sprints then the actual velocity of the team would be 20 points per Sprint.
- Take the story, sort all stories, first story is the easiest. Do the story, and calculate how much time do you need.
‣
Board
- Backlog
- Todo
- Bugs
- Development
- QA Queue
- QA Testing
- Ready for PROD
- DONE/Released
- To-do
- In progress
- Review
- Ready to test
- Test
- Done
