AGILE MANIFESTO |
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
AGILE PRINCIPLES |
- Satisfy the Customer – Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Embrace Change – Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Frequent Delivery – Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Cross-Functional Collaboration – Business people and developers must work together daily throughout the project.
- Support and Trust – Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Face-to-Face Conversation – The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working Software – Working software is the primary measure of progress.
- Sustainable Pace – Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Technical Excellence – Continuous attention to technical excellence and good design enhances agility.
- Keep it Simple – Simplicity–the art of maximizing the amount of work not done–is essential.
- Self-Organization – The best architectures, requirements, and designs emerge from self-organizing teams.
- Inspect and Adapt – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scrum is a framework, a specific implementation of the agile methodology. It is an iterative and incremental agile software development framework for managing software projects and product or application development. As mentioned in the Agile Process, Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The Scrum team is cross-functional; everyone is necessary to take a feature from idea to implementation.
ROLES | that are part of the Scrum framework
There are three core roles and some ancillary roles in the Scrum framework. There is a joke about a chicken and a pig. They are talking and the chicken says, “Let’s start a restaurant.” The pig replies, “Good idea, but what should we call it?” “How about ‘Ham and Eggs,'” says the chicken. “No thanks,” says the pig, “I’d be committed, you’d only be involved.”
The roles that are committed are the core roles and the roles that are only involved in the project are the ancillary roles.
CORE ROLES | The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). They represent the scrum team.
- Product Owner – The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.
- Development Team – The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs).
- Scrum Master – Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended.
ANCILLARY ROLES | The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum process—but nonetheless, they must be taken into account.
- Stakeholders – The stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews.
- Managers – People who control the work environment.
ARTIFACTS | produced during scrum framework implementations
- Product – The primary and the most important artifact of Scrum project is, of course, the product itself. The Scrum model expects the team to bring the product or system to a potentially shippable state at the end of each Scrum sprint.
- Product backlog – It is a prioritized features list, containing short descriptions of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers. Typically a product backlog consists of the following items – Features, Bugs, Technical work, Knowledge acquisition. The most predominant way for a Scrum team to express features on the agile product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user.
- Sprint backlog – The sprint backlog is the list of tasks identified by the Scrum team during sprint planning. During sprint planning, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the team to complete. It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to. The sprint backlog is very commonly maintained as a spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile.
- Sprint burn down chart – The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burn down, for example the release burn down chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burn down chart, which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.
OTHER KEYWORDS | in the Sprint framework
- Daily Scrum – On each day of a sprint, the team holds daily meetings (“the daily scrum”). Meetings are typically held in the same location and at the same time each day. Ideally, the daily scrum meeting is held in the morning, as it helps set the context for the coming day’s work. These Scrum daily standup meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.During the daily Scrum, each team member answers the following three questions:What did you do yesterday?What will you do today? Are there any impediments in your way?The daily Scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.
- Sprint – A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration.
- User Story – A feature described in the product backlog is commonly explained using a story and has a specific suggested structure. The structure of a story is: “As a <user type> I want to <do some action> so that <desired result>” This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand.
- Epic – An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break down into component stories.
- Spike – A period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or it might be accepted as one of many sprint delivery objectives.
- Tasks – Typically at the beginning of a sprint, the user stories are broken down into tasks and are assigned hours to them.
- Tracer Bullet – The tracer bullet is a spike with the current architecture, current technology set, and current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code.
- Sashimi – A report that something is “done”. The definition of “done” may vary from one Scrum team to another, but must be consistent within one team.
- Planning Poker – In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on the team’s velocity
- Sprint retrospective – Following one of the core principles of Agile to inspect and adapt. The Scrum team believes that there is always opportunity to improve. Although a good Scrum team will be constantly looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and to find ways to improve. This occurs during the sprint retrospective.
SUMMARY | of Scrum framework
- A product owner creates a prioritized wish list called a product backlog.
- During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces.
- The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
- Along the way, the ScrumMaster keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
- The sprint ends with a sprint review and retrospective.
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.