SCRUM

Scrum is a lightweight framework for agile development, one of the most used. Agile is a methodology that encourage fast inspection and adaptation. Encourage teamwork, self-organization, to delivery high quality software.

Scrum differentiates from other frameworks by having a set of roles, artifacts and time boxes. Scrum is most often used to manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic waterfall processes.

Scrum Roles

ScrumMaster

Is responsible for running the process smoothly, for removing obstacles that impact productivity, and for organizing and facilitating the critical meetings. The ScrumMaster should maintain a constant awareness of the status of the project (its progress to date) relative to the expected progress, investigate and facilitate resolution of any roadblocks that hold back progress, and generally be flexible enough to identify and deal with any issues that arise. The ScrumMaster is not a manager, but a facilitator.

Product Owner

The Product Owner is the keeper of the requirements. The Product Owner provides the "single source of truth" for the Team, regarding requirements and their planned order of implementation. Also, in charge to determine the objective, of the sprint.

Team

Is a self-organizing and cross-functional group of people who do the hands-on work of developing and testing the product. Since the Team is responsible for producing the product, it must also have the authority to make decisions about how to perform the work. The Team is therefore self-organizing: Team members decide how to break work into tasks, and how to allocate tasks to individuals, throughout the Sprint.

Scrum Artifacts

Product Backlog

Board where are gather all the requirements of the project. It is a living document, that can be updated at any time. It is a list of features, bugs, technical work or knowledge acquisition.

Sprint Backlog

List of items to be tackled during a sprint. It is a subset of the Product Backlog. Agreed by the Team and the Product Owner in the planning session.

Scrum Events

Daily Meeting

With a duration of no more of 15 minutes, Team owns the meeting and should speak in order to comment what is the plan for today, focus on meeting the objective of the Sprint. Avoid doing reporting, discussion should be based on the objective of the sprint, as Daily is not a status meeting. Raise if there are any blockers in the near future.

Meeting to decide what are the tasks planed for the next sprint, so during sprint there is no mismatch. Discussion can happens at this stage, but it should be as clear for everyone. Clear Acceptance Criteria from the business point of view, adding value to the project. It should be handle before the start next sprint.

Planning session

Where estimation of tickets come to place. Define and confirm the Goal for the sprint. Goal should be always be achievable. Review the capacity of the Team. Just before sprint is started.

Review session

With stakeholder and after sprint. Show delivery, progress and value added during the sprint.

Retro session

Discussion about what happened in last sprint. It is a safe space to talk about what went wrong, and how process can be improved.

Other Concepts

User stories/Use cases

Description of a feature in a narrative form. Written by the Product Owner, and responsibility of the same to keep up-to-date. The elements in this User Story are:

Name: The Name is a descriptive phrase or sentence. The example uses a basic "Role-Action-Reason" organization. It is important to have workable standard of some kind.
Description: This is a high-level (low-detail) description of the need to be met. For functional (user-facing) requirements, the description is put in narrative form. For non-functional requirements, the description can be worded in any form that is easy to understand. In both cases, the key is that the level of detail is modest, because the fine details are worked out during the implementation phase, in discussions between team members, product owners, and anyone else who is involved. (This is one of the core concepts of Scrum: Requirements are specified at a level that allows rough estimation of the work required to implement them, not in detail.)
Screens and External Documents: If the Story requires user-interface changes (especially non-trivial ones), the Story should contain or link to a prototype of the changes. Any external documents required to implement the Story should also be listed.
How to test: The implementation of a Story is defined to be complete if, and only if, it passes all acceptance tests developed for it. This section provides a brief description of how the story will be tested. As for the feature itself, the description of testing methods is short, with the details to be worked out during implementation, but we need at least a summary to guide the estimation process.

Story

Not all requirements for new development represent user-facing features, but do represent significant work that must be done. These requirements often, but not always, represent work that must be done to support user-facing features. We call these non-functional requirements Technical Stories. Technical Stories have the same elements as User Stories, but need not be cast into narrative form if there is no benefit in doing so. Technical Stories are usually written by Team members, and are added to the Product Backlog. The Product Owner must be familiar with these Stories, and understand the dependencies between these and User Stories in order to rank (sequence) all Stories for implementation.

Defect

A Defect, or bug report, is a description of a failure of the product to behave in the expected fashion. Defects are stored in a bug-tracking system, which may or may not be physically the same system used to store the Product Backlog. If not, then someone (usually the Product Owner) must enter each Defect into the Product Backlog, for sequencing and scheduling.

Sprint

Fixed time duration to accomplish an agreed objective, with value by the Team, which can be potentially be deliver to production/final stage. Usually 2 weeks.

Story Points

Measurement of effort of a certain Story. experience, complexity and load of work are taken into account. It must be taken by the Team. Objective, is to have an agreement of the effort of the Story. TL usually explain task to the team, doubts are solved. TL is not the one who decided, but Team. Notes are taken. Once is clear, values from a Fibonacci sequence are assigned to the Story. 1, 2, 3, 5, 8, 13, 21. 1 is the lowest effort, 21 is the greatest effort. More than 21, should be split in smaller User Stories. Discuss with team regarding any particular difference on estimation, and agreed the effort.

Personal experience

Not everything is closed at the beginning of the sprint. Flexibility to learn. Focus on objective of the sprint, complete task and give value to the product. Communication is key. It is not about the person, is the Team.