Development scrum

Содержание страницы

Scrum Methodology

The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.

An Empirical Framework For Learning (Not a Methodology)

The Scrum Reference Card

Scrum is part of the Agile movement. Agile is a response to the failure of the dominant software development project management paradigms (including waterfall) and borrows many principles from lean manufacturing. In 2001, 17 pioneers of similar methods met at the Snowbird Ski Resort in Utah and wrote the Agile Manifesto, a declaration of four values and twelve principles. These values and principles stand in stark contrast to the traditional Project Manager’s Body Of Knowledge (PMBOK). The Agile Manifesto placed a new emphasis on communication and collaboration, functioning software, team self organization, and the flexibility to adapt to emerging business realities.

How Does Scrum Fit With Agile?

The Agile Manifesto doesn’t provide concrete steps. Organizations usually seek more specific methods within the Agile movement. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. While I like all the Agile approaches, for my own team Scrum was the one that enabled our initial breakthroughs. Scrum’s simple definitions gave our team the autonomy we needed to do our best work while helping our boss (who became our Product Owner) get the business results he wanted. Scrum opened our door to other useful Agile practices such as test-driven development (TDD). Since then we’ve helped businesses around the world use Scrum to become more agile. A truly agile enterprise would not have a “business side” and a “technical side.” It would have teams working directly on delivering business value. We get the best results when we involve the whole business in this, so those are the types of engagements I’m personally the most interested in.

What’s The Philosophy Behind Scrum?

Scrum’s early advocates were inspired by empirical inspect and adapt feedback loops to cope with complexity and risk. Scrum emphasizes decision making from real-world results rather than speculation. Time is divided into short work cadences, known as sprints, typically one week or two weeks long. The product is kept in a potentially shippable (properly integrated and tested) state at all times. At the end of each sprint, stakeholders and team members meet to see a demonstrated potentially shippable product increment and plan its next steps.

Scrum is a simple set of roles, responsibilities, and meetings that never change. By removing unnecessary unpredictability, we’re better able to cope with the necessary unpredictability of continuous discovery and learning.

Scrum Roles

Scrum has three roles: Product Owner, Scrum Master, and Team.

The Example Scrum Master’s Checklist

  • Product Owner: The Product Owner should be a person with vision, authority, and availability. The Product Owner is responsible for continuously communicating the vision and priorities to the development team.

It’s sometimes hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.

  • Scrum Master: The Scrum Master acts as a facilitator for the Product Owner and the team. The Scrum Master does not manage the team. The Scrum Master works to remove any impediments that are obstructing the team from achieving its sprint goals. This helps the team remain creative and productive while making sure its successes are visible to the Product Owner. The Scrum Master also works to advise the Product Owner about how to maximize ROI for the team.
  • Team: According to Scrum’s founder, “the team is utterly self managing.” The development team is responsible for self organizing to complete work. A Scrum development team contains about seven fully dedicated members (officially 3-9), ideally in one team room protected from outside distractions. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. The team has autonomy and responsibility to meet the goals of the sprint.
  • Scaled Agile

    When several teams work on one product, they should generally use a single Product Owner (who can make real business decisions) and a single Product Backlog with customer-centric requirements. Each Scrum team should strive to become a feature team, able to build a complete slice of product which could be delivered to a customer. When interdependencies arise, Scrum’s feature teams must learn to use team self organization principles to coordinate with other teams. Unfortunately, most teams are not initially accustomed to this level of responsibility, and pre-existing management habits and hierarchies present organizational impediments. Scrum eliminates traditional co-ordination roles such as project manager and PMO, as these interfere with team self organization. Scrum eliminates traditional technical czar roles such as “architect,” as technical decisions are made by collaborative teams.

    While optimal Agility requires fundamental changes to organizational design, it’s tempting to use one of the hybrid approaches that combine a watered-down version of Scrum with traditional hierarchical management. Large organizations that are more committed to the values and principles of the Agile Manifesto are advised to learn about Large Scale Scrum (LeSS).

    Learn More

    Online Scrum Master training is available in the Scrum Training Series, a free collection of entertaining e-learning modules covering an Introduction to Scrum, the Backlog Grooming Meeting, the Sprint Planning Meeting, the Daily Scrum Meeting, the Sprint Review Meeting, and the Sprint Retrospective Meeting. You can download the 6-page Scrum Reference Card or learn what the Scrum Master does. In person Certified Scrum Master training, typically using group immersion activities and case studies, is also available all over the world.

    About The Author

    This article was rewritten by Michael James, an Agile coach and Certified Scrum Trainer for CollabNet, Inc. For additional information or questions, please email: or call 1.844.301.1252 (Toll Free within the USA)

    Comments Feed

    Reader’s Comments

    1. Ethan Moore | August 20th, 2017 at 9:35 pm

    Rightly said.Another very untrue notion is the fear of having very loose project plan and project completion date.They think that with less control over the project, they would be able to monitor the progress and project will go on forever.
    If you convince the management about these 4 points, they are most likely to agree or at least try out the Agile/Scrum.For more, Please Visit:

    Nice article Michael..In recent years, it has become evident that organizations which use Scrum as their preferred project delivery framework consistently deliver high Returns on Investment. Scrum’s focus on value-driven delivery helps Scrum Teams deliver results as early in the project as possible.We have developed an article on Agile and Scrum. You can click on the following link to get through.

    Thanks for this..

    We are in the process of understanding the framework, so we can implement it into our business.

    Hi, thank you for this post I agree with you that Scrum is part of the Agile movement. Agile is a response to the failure of the dominant software development project management paradigms (including waterfall) and borrows many principles from lean manufacturing. very useful information

    Wow thats great about scrum methodology. Please suggest me best course of scrum master. Is this possible to get a good job after getting the scrum course.

    kindly explain the ” sprint planning meeting “?

    There is a very nice 5 min video summarizing Scrum in 5 minutes in following link:

    It was really worthful and helpful.

    Hi Scrum Methodology,

    I am UI/UX, web and mobile graphics designer and developer looking for work.

    Above you can find any kind of design work you need. My portfolio is the largest
    web design portfolio on the Internet. It contains 180 designs sorted under 35 categories.

    This is a very well arranged introduction to the Scrum.
    It is put in very simple manner and quite easy to understand.
    Few tricky questions in Quiz helped in clearing misconception of the topic.

    It gives sufficient confidence to prepare for CSM course and certification exam.

    Thanks and best regards,

    A very well made explanation of what Agile and Scrum is , This will be great for people new to Agile who are looking to learn and implement Scrum in their companies. The article is very easy to understand and the background info about Agile and how it got developed is great knowledge even for people already using Agile.

    Great content ! Thanks Michael!
    Its interesting to compare this content with content on another website

    Hello, its pleasant piece of writing concerning media print,
    we all be familiar with media is a wonderful source of data.

    Seems the slides are not working today. Please kindly fix it and let me know.

    Clement Chu

    Michael James, please continue to share your insights – invaluable

    Thank you KEVIN for the insight. Will definitely adopt for our projects in South Africa

    @Kevin….damn right…. It’s a way of life. 😉

    Hi Micheal,
    Astonished with the explanation and Interactive sessions implemented. Getting in Par to the standards fixed needs courage. Good Job done.

    One of the best presentation i ever had.
    Thank You so much.

    can we compare scrum sprints with Brain storming sessions ,what we practice in management for getting quicker solutions.?

    Hi Michael, I am in the process of introducing scrum into our company and was struck a fair few points. Your presentation is awesome and really opened my eyes. Thank you so much for sharing

    Scrum is not a methodology.

    I have been practicing a mix of scrum, v-model and waterfall methodology without realising how our practice had changed. I am new to the idea of scrum and frankly speaking I love the idea. But truly the methodology can only be sucessful if the whole team are geared psychologically towards it.
    I love the presentation, and I kinda stumbled on it but now I have downloaded lots of videos and material with a mindset of gearing our processes to scrum.

    Thanks a lot for this. The video is easy to get.

    What is Agile | What is Scrum?

    Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Below are the most frequently asked questions around Agile and Scrum, answered by our experts.

    Getting Started with Agile

    Diving Deeper with Agile

    Next Steps with Agile

    Resources you might be interested in:

    Talk to an expert about Agile!

    Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods or Agile processes generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Agile development refers to any development process that is aligned with the concepts of the Agile Manifesto. The Manifesto was developed by a group fourteen leading figures in the software industry, and reflects their experience of what approaches do and do not work for software development. Read more about the Agile Manifesto. Did you know thatAgile can also be applied to hardware projects? Learn about cPrime’s revolutionary Agile for Hardware framework.

    Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one.

    • A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
    • “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.

    A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined below. 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 processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals. An agile Scrum process benefits the organization by helping it to

    • Increase the quality of the deliverables
    • Cope better with change (and expect the changes)
    • Provide better estimates while spending less time creating them
    • Be more in control of the project schedule and state

    Benefits to Customer

    Customers find that the vendor is more responsive to development requests. High-value features are developed and delivered more quickly with short cycles, than with the longer cycles favored by classic “waterfall” processes.

    Benefits to Vendors

    Vendors reduce wastage by focusing development effort on high-value features, and reduce time-to-market relative to waterfall processes due to decreased overhead and increased efficiency. Improved customer satisfaction translates to better customer retention and more positive customer references.

    Benefits to Development Teams

    Team members enjoy development work, and like to see their work used and valued. Scrum benefits Team members by reducing non-productive work (e.g., writing specifications or other artifacts that no one uses), and giving them more time to do the work they enjoy. Team members also know their work is valued, because requirements are chosen to maximize value to customers.

    Benefits to Product Managers

    Product Managers, who typically fill the Product Owner role, are responsible for making customers happy by ensuring that development work is aligned with customer needs. Scrum makes this alignment easier by providing frequent opportunities to re-prioritize work, to ensure maximum delivery of value.

    Benefits to Project Managers

    Project Managers (and others) who fill the ScrumMaster role find that planning and tracking are easier and more concrete, compared to waterfall processes. The focus on task-level tracking, the use of Burndown Charts to display daily progress, and the Daily Scrum meetings, all together give the Project Manager tremendous awareness about the state of the project at all times. This awareness is key to monitoring the project, and to catching and addressing issues quickly.

    Benefits to PMOs and C-Level Executives

    Scrum provides high visibility into the state of a development project, on a daily basis. External stakeholders, such as C-Level executives and personnel in the Project Management Office, can use this visibility to plan more effectively, and adjust their strategies based on more hard information and less speculation.

    Scrum does not define just what form requirements are to take, but simply says that they are gathered into the Product Backlog, and referred to generically as “Product Backlog Items,” or “PBIs” for short. Given the time-boxed nature of a Sprint, we can also infer that each set should require significantly less time to implement than the duration of the Sprint. Most Scrum projects borrow the “XP” (Extreme Programming) practice of describing a feature request as a “User Story,” although a minority uses the older concept of a “Use Case.” We will go with the majority view here, and describe three reasonably-standard requirements artifacts found in Product Backlogs.

    User Story

    A User Story describes a desired feature (functional requirement) in narrative form. User Stories are usually written by the Product Owner, and are the Product Owner’s responsibility. The format is not standardized, but typically has a name, some descriptive text, references to external documents (such as screen shots), and information about how the implementation will be tested. For example, a Story might resemble the following:

    The elements in this User Story are:

    1. Name: The Name is a descriptive phrase or sentence. The example uses a basic “Role-Action-Reason” organization. Another common style, popularized by Mike Cohn, follows the template “As a , I want so that .” The choice of template is less important than having a workable standard of some kind.
    2. 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.)
    3. 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.
    4. 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.

    There are two reasons for including the information about how to test the Story. The obvious reason is to guide development of test cases (acceptance tests) for the Story. The less-obvious, but important, reason, is that the Team will need this information in order to estimate how much work is required to implement the story (since test design and execution is part of the total work).


    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.


    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.

    The three roles defined in Scrum are the ScrumMaster, the Product Owner, and the Team (which consists of Team members). The people who fulfill these roles work together closely, on a daily basis, to ensure the smooth flow of information and the quick resolution of issues.


    The ScrumMaster (sometimes written “Scrum Master,” although the official term has no space after “Scrum”) is the keeper of the process. The ScrumMaster is responsible for making the process run smoothly, for removing obstacles that impact productivity, and for organizing and facilitating the critical meetings. The ScrumMasters responsibilities include

    • Removing the barriers between the development Team and the Product Owner so that the Product Owner directly drives development. Can we have the feature image on the posting link to the article as well
    • Looks like there are some mismatched categories when you filter (see screenshot Atlasssian configurations displays a business agility article)
    • Looks like search functionality is bringing in products and pages in addition to posts

    Teach the Product Owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
    Improve the lives of the development Team by facilitating creativity and empowerment.
    Improve the productivity of the development Team in any way possible.
    Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
    Keep information about the Team’s progress up to date and visible to all parties.

    In practical terms, the ScrumMaster needs to understand Scrum well enough to train and mentor the other roles, and educate and assist other stakeholders who are involved in the process. 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, in any way that is required. The ScrumMaster must protect the Team from disturbance from other people by acting as the interface between the two. The ScrumMaster does not assign tasks to Team members, as task assignment is a Team responsibility. The ScrumMaster’s general approach towards the Team is to encourage and facilitate their decision-making and problem-solving capabilities, so that they can work with increasing efficiency and decreasing need for supervision. The goal is to have a team that is not only empowered to make important decisions, but does so well and routinely.

    Download the Scrum Master Role Cheatsheet

    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. In practice, the Product Owner is the interface between the business, the customers, and their product related needs on one side, and the Team on the other. The Product Owner buffers the Team from feature and bug-fix requests that come from many sources, and is the single point of contact for all questions about product requirements. Product Owner works closely with the team to define the user-facing and technical requirements, to document the requirements as needed, and to determine the order of their implementation. Product Owner maintains the Product Backlog (which is the repository for all of this information), keeping it up to date and at the level of detail and quality the Team requires. The Product Owner also sets the schedule for releasing completed work to customers, and makes the final call as to whether implementations have the features and quality required for release.

    Download the Product Owner Role Cheatsheet

    The 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. The Team size should be kept in the range from five to nine people, if possible. (A larger number make communication difficult, while a smaller number leads to low productivity and fragility.) Note: A very similar term, “Scrum Team,” refers to the Team plus the ScrumMaster and Product Owner.


    Scrum is an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process.

    What is Scrum?

    In the agile Scrum world, instead of providing complete, detailed descriptions of how everything is to be done on a project, much of it is left up to the Scrum software development team. This is because the team will know best how to solve the problem they are presented.

    This is why in Scrum development, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to a set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, Exit criteria (ETVX) and so on, as would be provided in most methodologies.

    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.

    And in Scrum, a team is cross functional, meaning everyone is needed to take a feature from idea to implementation.

    Within agile development, Scrum teams are supported by two specific roles. The first is a ScrumMaster, who can be thought of as a coach for the team, helping team members use the Scrum process to perform at the highest level.

    The product owner (PO) is the other role, and in Scrum software development, represents the business, customers or users, and guides the team toward building the right product.

    Scrum Development: What’s Involved?

    The Scrum model suggests that projects progress via a series of sprints. In keeping with an agile methodology, sprints are timeboxed to no more than a month long, most commonly two weeks.

    Scrum methodology advocates for a planning meeting at the start of the sprint, where team members figure out how many items they can commit to, and then create a sprint backlog – a list of the tasks to perform during the sprint.

    During an agile Scrum sprint, the Scrum team takes a small set of features from idea to coded and tested functionality. At the end, these features are done, meaning coded, tested and integrated into the evolving product or system.

    On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner. This meeting is timeboxed to no more than 15 minutes. During that time, team members share what they worked on the prior day, will work on that day, and identify any impediments to progress.

    The Scrum model sees daily scrums as a way to synchronize the work of team members as they discuss the work of the sprint.

    At the end of a sprint, the team conducts a sprint review during which the team demonstrates the new functionality to the PO or any other stakeholder who wishes to provide feedback that could influence the next sprint.

    This feedback loop within Scrum software development may result in changes to the freshly delivered functionality, but it may just as likely result in revising or adding items to the product backlog.

    Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting, including the ScrumMaster and PO. The meeting is an opportunity to reflect on the sprint that has ended, and identify opportunities to improve.

    Scrum Process: The Main Artifacts

    The primary artifact in Scrum development 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.

    The product backlog is another artifact of Scrum. This is the complete list of the functionality that remains to be added to the product. The product owner prioritizes the backlog so the team always works on the most valuable features first.

    The most popular and successful way to create a product backlog using Scrum methodology is to populate it with user stories, which are short descriptions of functionality described from the perspective of a user or customer.

    In Scrum project management, on the first day of a sprint and during the planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team’s to-do list for the sprint, whereas a product backlog is a list of features to be built (written in the form of user stories).

    The sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality it committed to deliver during the sprint.

    Additional artifacts resulting from the Scrum agile methodology is the sprint burndown chart and release burndown chart. Burndown charts show the amount of work remaining either in a sprint or a release, and are an effective tool in Scrum software development to determine whether a sprint or release is on schedule to have all planned work finished by the desired date.

    The Agile Scrum Project: Main Roles

    Even if you are new to Scrum, you may have heard of a role called the ScrumMaster. The ScrumMaster is the team’s coach, and helps Scrum practitioners achieve their highest level of performance.

    In the Scrum process, a ScrumMaster differs from a traditional project manager in many ways, including that this role does not provide day-to-day direction to the team and does not assign tasks to individuals.

    A good ScrumMaster shelters the team from outside distractions, allowing team members to focus maniacally during the sprint on the goal they have selected.

    While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team to the right goal. The product owner does this by creating a compelling vision of the product, and then conveying that vision to the team through the product backlog.

    The product owner is responsible for prioritizing the backlog during Scrum development, to ensure it’s up to par as more is learned about the system being built, its users, the team and so on.

    The third and final role in Scrum project management is the Scrum team itself. Although individuals may join the team with various job titles, in Scrum, those titles are insignificant. Scrum methodology states that each person contributes in whatever way they can to complete the work of each sprint.

    This does not mean that a tester will be expected to re-architect the system; individuals will spend most (and sometimes all) of their time working in whatever discipline they worked before adopting the agile Scrum model. But with Scrum, individuals are expected to work beyond their preferred disciplines whenever doing so would be for the good of the team.

    One way to think of the interlocking nature of these three roles in this agile methodology is as a racecar.

    The Scrum team is the car itself, ready to speed along in whatever direction it is pointed. The product owner is the driver, making sure that the car is always going in the right direction. And the ScrumMaster is the chief mechanic, keeping the car well tuned and performing at its best.


    A brief look into using the scrum framework for software development

    Browse topics


    Scrum is one of the most popular frameworks for implementing agile. So popular, in fact, that many people think scrum and agile are the same thing. (They’re not.) Many frameworks can be used to implement agile, such as kanban for example, but scrum has a unique flavor because of the commitment to short iterations of work.

    Scrum articles


    A sprint is a short, time boxed period when a scrum team works to complete a set amount of work.

    Sprint Planning

    Sprint Planning is an event in scrum that defines what can be delivered in the upcoming sprint and how that work will be achieved.

    Four agile ceremonies, demystified

    Learn how to facilitate great agile ceremonies like sprint planning, daily stand-ups, iteration review and retrospectives.

    The product backlog: your ultimate to-do list

    What is a product backlog in agile or scrum? Learn about the best practices for managing and prioritizing a healthy product backlog.

    Three steps to better sprint reviews

    Learn how sprint reviews demonstrate the hard work of the entire team: designers, developers, and the product owner.

    Standups for agile teams

    Learn how standups contribute to a healthy agile program and some tips and tricks for you and your team.

    What is a Scrum Master?

    Learn what a Scrum Master is (and what they are NOT), and how the role supports and works with other members of an agile team.

    Agile retrospectives: Use the past to define the future

    A retrospective helps teams perform better over time. See what the agile community is saying and learn how to run your own retrospective meetings.

    Learn scrum with Jira Software

    A step-by-step guide on how to drive a scrum project, prioritize and organize your backlog into sprints, run the scrum ceremonies and more, all in Jira.

    What’s so special about scrum?

    With scrum, the product is built in a series of fixed-length iterations called sprints that give teams a framework for shipping software on a regular cadence. Milestones–i.e., the end of a sprint–come frequently, bringing with them a feeling of tangible progress with each cycle that focuses and energizes everyone. («Continuous inspiration» for the win!) Short iterations also reinforce the importance of good estimation and fast feedback from tests–both recurring struggles in waterfall projects.

    Scrum calls for four ceremonies that bring structure to each sprint:

    • Sprint planning: A team planning meeting that determines what to complete in the coming sprint.
    • Daily stand-up: Also known as a daily scrum, a 15-minute mini-meeting for the software team to sync.
    • Sprint demo: A sharing meeting where the team shows what they’ve shipped in that sprint.
    • Sprint retrospective: A review of what did and didn’t go well with actions to make the next sprint better.

    During a sprint, visual artifacts like task boards and burndown charts, visible to the team and spectators alike, are powerful motivators. They drive a spirit of «we’re doing this!» Having the opportunity to show off new work at the sprint demo is equally motivating, and the consistent, incremental feedback the team gets from stakeholders at each demo creates a powerful way to develop products.

    Scrum done well–which is to say, not «waterfall with stand-ups»–can be a massive catalyst for improving team productivity and morale, and the product development process as a whole.

    Three essential roles for scrum success

    A scrum team has a slightly different composition than a traditional waterfall project, with three specific roles: product owner, scrum master, and the development team. And because scrum teams are cross-functional, «the development team» includes testers, designers, and ops engineers in addition to developers.

    The product owner

    Product owners are the champions for their product. They are focused on understanding business and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:

    • Build and manage the product backlog
    • Closely partner with the business and the team to ensure everyone understands the work items in the product backlog
    • Give the team clear guidance on which features to deliver next
    • Decide when to ship the product with the predisposition towards more frequent delivery

    Keep in mind that a product owner is not a project manager. Product owners are not managing the status of the program. They focus on ensuring the development team delivers the most value to the business. Also, it’s important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.

    The scrum master

    Scrum masters are the champion for scrum within their team. They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. An effective scrum master deeply understands the work being done by the team and can help the team optimize their delivery flow. As the facilitator-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.

    Scrum masters also look to resolve impediments and distractions for the development team, insulating them from external disruptions whenever possible.

    Part of the scrum master’s job is to defend against an anti-pattern common among teams new to scrum: changing the sprint’s scope after it has already begun. Product owners will sometimes ask, «Can’t we get this one more super-important little thing into this sprint?» But keeping scope air tight reinforces good estimation and product planning–not to mention fends off a source of disruption to the development team.

    Scrum masters are commonly mistaken for project managers, when in fact, project managers don’t really have a place in the scrum methodology. A scrum team controls its own destiny and self-organizes around their work. Agile teams use pull models where the team pulls a certain amount of work off the backlog and commits to completing it that sprint, which is very effective in maintaining quality and ensuring optimum performance of the team over the long-term. Neither scrum masters nor project managers nor product owners push work to the team (which, by contrast, tends to erode both quality and morale).

    The scrum team

    Strong scrum teams approach their project with a strong «we» attitude.

    Scrum teams are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually 5 to 7 members. Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. All members of the team help one another to ensure a successful sprint completion.

    As mentioned above, the scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.

    But wait: there’s more

    Ok: so now you’ve been briefed. But understanding the philosophy of scrum and who is on a scrum team is only half of the equation. Keep reading to learn how scrum team members work together using common agile ceremonies as well as how the team in an agile program delivers work back to the business.

    Agile has had a huge impact on me both professionally and personally as I’ve learned the best experiences are agile, both in code and in life. You’ll often find me at the intersection of technology, photography, and motorcycling. Find me on Twitter! @danradigan

    มาทำความรู้จักกับ “Agile and Scrum” แนวคิดการทำงานของบริษัทยุคใหม่

    ผมคิดว่าผู้อ่านชาว Brand Inside น่าจะพอคุ้นหูหรือเคยผ่านตากับคำว่า “Agile” หรือ “Scrum” มาอยู่บ้างแล้ว ด้วยที่เป็นวัฒนธรรมองค์กรที่ค่อนข้างแพร่หลายในเหล่าบรรดาบริษัท Tech Company โดยเฉพาะอย่างยิ่งในเหล่า Startup แต่สำหรับคนที่ไม่รู้จัก วันนี้ผมจะเล่าให้ฟังถึง ‘Agile amd Scrum’ ในภาพรวมว่าเป็นอย่างไรครับ

    ก่อนอื่นต้องบอกว่า ‘Agile’ ไม่ใช่รูปแบบการทำงานแต่เป็นแนวคิดในการทำงานที่เป็นทางเลือกอีกทางหนึ่ง เพราะก่อนหน้านี้องค์กรส่วนใหญ่จะทำงานด้วยระบบ Project Management คือมี Project Manager และทีมมานั่งวางแผนกันก่อนเริ่มโปรเจ็คต์ ทั้งเรื่องเงิน เวลา คน และอื่นๆ ตั้งแต่เริ่มต้นจนจบโปรเจ็คต์ ซึ่งเป็นงานทำงานแบบ ‘Waterfall Process’ แต่แนวคิด Agile จะส่งผลให้มีรูปแบบการทำงานที่ต่างออกไป

    การทำงานแบบ ‘Waterfall Process’ // ที่มา :

    ซึ่งแท้จริงแล้ว Agile นั้นเกิดขึ้นมาจากบริษัทที่ทำในเชิง Software Development เป็นหลัก เพราะปัญหาของระบบเดิมที่บรรดาบริษัท Software เจอก็คือ

    • ความยากในการวางแผน การนั่งคิดทุกอย่างตั้งแต่เริ่มจนถึงจบโปรเจ็คต์นั้น เป็นเรื่องยากที่จะวางแผนทุกอย่างได้ลงตัวและแม่นยำ ทั้งในเรื่องของงบประมาณที่อาจจะบานปลายหรือเวลาที่ไม่ลงตัว
    • กว่าจะรู้ว่าผิดพลาดก็อาจจะสายไปเสียแล้ว ในระบบแบบ Waterfall กว่าที่จะมีการทดสอบโปรดักส์หรือ Software นั้นก็ต้องเป็นในขั้น Test ซึ่งการ Design + Develop นั้นแทบจะเสร็จอยู่แล้ว ถ้าไปเจอความผิดพลาดตอนนี้ไม่ว่าจะด้วยเข้าใจ Requiement ผิดพลาดหรือมีการเปลี่ยนแปลงก็ตามแต่ การแก้ไขก็จะทำได้ยาก (บางครั้งอาจถึงขั้นต้องรื้อทำใหม่)

    เพื่อจัดการกับปัญหาเหล่านี้ แนวคิด Agile ก็เลยถูกนำมาประยุกต์ใช้คือแทนที่จะวางแผน กำหนดเป้าหมายและมุ่งไปในครั้งเดียว ก็เปลี่ยนเป็นวางแผนและทำงานไปทีละนิดๆ และคอยประเมินว่าไปต่อได้ดีไหม ไปถูกทางไหม แล้วจึงไปต่อ กำหนดเป้าระยะสั้นและค่อยๆ ไป เพื่อที่เมื่อเจอปัญหาจะได้แก้ไขง่ายขึ้น หรือเมื่อ Requirment เกิดการเปลี่ยนแปลงก็สามารถรับมือได้ดีขึ้น

    เปรียบเทียบระหว่าง ‘Waterfall’ กับ ‘Agile’ // ที่มา :

    แนวคิดสำคัญของ Agile

    จริงๆ Agile นั้นไม่ได้มีการระบุเป็นกฎไว้อย่างชัดเจน ผมขอสรุปจากการประสบด้วยตัวเองและอ่านจากหลายๆ ที่ไว้ให้แล้วกันครับ โดยหลักการสำคัญของ Agile ที่เห็นได้ชัดๆ นั้นจะประกอบไปด้วย

    • ไม่เน้นกระบวนการและเอกสาร ให้เน้นไปที่การพัฒนาโปรดักส์ให้ดีที่สุดมากกว่าจะยึดติดกับเอกสารต่างๆ (ไม่ใช่ว่าไม่จำเป็นแต่ให้ความสำคัญน้อยกว่า) คือต่อให้มีเอกสารยืนยันแล้วว่าจะทำอะไร แต่มีอีกทางที่ส่งมอบ Value ให้กับลุกค้าได้ดีกว่า Agile จะเลือกทางนั้น ไม่ใช่ทางเอกสาร
    • ยอมรับความเปลี่ยนแปลง เพราะ requirement อาจเปลี่ยนแปลงได้ตลอด แนวคิดแบบ Agile จะไม่ฟูมฟายกับการเปลี่ยนแปลง ไม่มีการทำงานหรือยึดติดกับ Gantt Chart แต่จะทำงานแบบ ค่อนข้าง Flexible ตามสิ่งที่เกิดขึ้นจริงเป็นหลัก สามารถเปลี่ยนแปลงได้ตลอดเวลา
    • ทำทีละนิดแต่ทำบ่อยๆ คือมีการส่งมอบงานอะไรบางอย่างให้ทีมหรือลูกค้าอย่าต่อเนื่องทีละเล็กทีละน้อย เช่นส่งมอบอะไรใหม่ทุกๆ 2 อาทิตย์หรือทุกๆ เดือน จะไม่ให้ลูกค้ามีการรอ 3-6 เดือนเพื่อรอโปรเจ็คต์ใหญ่เสร็จแล้วค่อยส่งมอบทีเดียว
    • ผิดพลาดให้เร็ว คือไม่กลัวที่จะลงมือทำเพื่อที่จะเจอกับความผิดพลาดและแก้ไขไปทีละนิด จะไม่ใช่การวางแผนโดยละเอียดเพื่อป้องกันความผิดพลาด แต่พอเจอสิ่งที่ผิดไปจากแผนจริงๆ (เพราะอย่างที่รู้ว่าน้อยครั้งนักที่เราจะทำตามแผนได้ทั้งหมด) ก็อยู่ในภาวะที่เป็น Point of No Return ไปแล้ว
    • ทำงานเป็นทีมมากกว่าที่จะสนใจกระบวนการ คือเน้นที่การมีปฏิสัมพันธ์ระหว่างบุคคลมากกว่าที่บอกว่าต้องเป็นไปตามกระบวนการ มีปัญหาอะไรให้พูดคุยกับทีมเลยทันที บางครั้งอาจถึงขั้นเอา Programmer ไปเจอลูกค้าเพื่อให้เข้าใจ requirement ที่แท้จริงด้วย ให้ลูกค้าเข้ามามีส่วนร่วมตั้งแต่เริ่มกระบวนการ ซึ่งทีมมักจะประกอบด้วยหลายๆ ตำแหน่ง และมีอำนาจมากพอที่จะตัดสินใจทำหรือไม่ทำอะไรเพื่อ Drive ให้งานที่ทีมรับผิดชอบสำเร็จตามเป้าหมาย

    ข้อดีของการทำงานในแนวคิด Agile หลักๆ คือการไม่มีกำแพงระหว่างฝ่าย เพราะเอาทุกฝ่ายมาอยู่ในทีมเดียวกัน เน้นที่การสื่อสารระหว่างบุคคล ทำให้ลดความไม่เข้าใจลงไป และสามารถแก้ปัญหาได้รวดเร็วๆ (สมมติว่า Test แล้วมีปัญหา ก็สามารถบอกกับ Designer หรือ Programmer ให้แก้ไขได้ทันที โดยไม่ต้องส่งเรื่องข้ามฝ่าย) รวมถึงการที่ค่อยๆ ส่งมอบงานทีละนิดทำให้มีความยืดหยุ่นในการทำงานสูง

    ซึ่งแนวคิดแบบ ‘Agile’ มักจะมาคู่กับกรอบการทำงาน (Framework) แบบ ‘Scrum’

    จริงๆ ต้องบอกว่า Framework ภายใต้แนวคิด Agile นั้นมีหลากหลายวิธี แต่ ‘Scrum’ เป็นวิธีการทำงานที่ได้รับความนิยมมากที่สุดสำหรับการทำงานภายใต้แนวคิดนี้ มันคือวิธีการทำงานที่ให้ ‘ทีมช่วยกันรุมงาน’ (ถึงได้เรียกว่า Scrum ไงหละ!) ซึ่งในวิธีการทำงานแบบ Scrum จะไม่มี Project Manager, Design, Analyst, Tester (และอื่นๆ) แต่จะมีเพียงแค่ 3 ตำแหน่งสำคัญคือ

    1. Product Owner : มีหน้าที่ประเมิน Values และจัด Priorities ของ Tasks ต่างๆ ให้กับทีม
    2. Scrum Master : เป็นผู้ทำให้การทำงานเป็นไปอย่างลื่นไหล ซึ่งไม่ได้หมายถึงการเป็นผู้นำทีม แต่จะคอยกำจัดอุปสรรคที่ขัดขวางไม่ให้ทีมบรรลุเป้าหมาย
    3. Team : จะทำงานแบบ Self-Management ซึ่งในหนึ่งทีมจะประกอบด้วยคนประมาณ 3-9 คน และรวมทุกตำแหน่งทั้ง Designer, Programmer, UI/UX, Testing เข้าด้วยกัน เพื่อให้ทีมหนึ่งทีมสามารถทำงานตั้งแต่ต้นจนจบได้ด้วยตัวเอง โดยไม่ต้องข้ามแผนก

    วิธีการทำงานของ Scrum ก็จะประกอบไปด้วยสิ่งที่น่าสนใจดังนี้

    • Backlog : เป็น Task งานที่ต้องทำ ทั้ง requirement ของลูกค้าและทีม ซึ่ง Product Owner จะเป็นคนตัดสินใจนำ Task ต่างๆ เหล่านี้เข้าไปใน Sprint ตามลำดับความสำคัญ (ส่วนใหญ่แล้วก็จะพิจารณาด้วย Value ของ Task นั้นๆ เมื่อแลกกับ effort ที่ต้องใช้)
    • Sprint Phase : อย่างที่บอกว่า Agile นั้น เน้นการส่งงานให้เร็วและบ่อย ซึ่ง Period นั้นจะเรียกว่า Sprint โดยมีกำหนดประมาณ 2-4 สัปดาห์ โดยเป้าหมายของ Sprint คือการ Deliver บางสิ่งบางอย่างให้สำเร็จ (Task ที่ Product Owner ได้ประเมินว่าควรทำตั้งแต่ก่อนเริ่ม Sprint) ซึ่งเมื่อจบ Sprint ก็จะมีการ Review ผลงาน (Sprint Review) ให้กับคนอื่นๆ ที่เกี่ยวข้องอาจจะเป็นทีมเซลล์ Users หรือลูกค้า เพื่อให้รับทราบถึงความคืบหน้าของโปรเจ็คต์อยู่เรื่อยๆ
    • Daily Scrum Meeting : ในทุกๆ เช้าทีมจะมีการประชุมสั้นๆ 10-15 นาที เพื่อบอกว่าเมื่อวานทำอะไร วันนี้จะทำอะไร และมีปัญหาอะไรบ้าง เพื่อให้การทำงานในทุกๆ วันเป็นไปอย่างราบรื่น ,รู้ว่ากำลังเดินเข้าสู่เป้าหมายหรือยัง และมีการแก้ไขปัญหาอย่างต่อเนื่อง

    Scrum Framwork // ที่มา :

    ข้อจำกัดของการประยุกต์ใช้ Agile

    • การประยุกต์ใช้ในองค์กรใหญ่ค่อนข้างทำได้ยาก เพราะมีทีมและแผนกที่ค่อนข้างใหญ่ การให้ทุกคนยอมรับวัฒนธรรมนี้ค่อนข้างเป็นไปได้ยาก รวมถึงการแตกฝ่ายต่างๆ เพื่อมารวมเป็นทีมย่อยขนาดเล็กก็ทำได้ยาก
    • Agile เป็นแนวคิดที่ค่อนข้างซัพพอร์ตกับระบบแบบ Flat Organization เพราะฉะนั้นสำหรับบางบริษัทหรือบริษัทที่ผู้บริหารมีแนวคิดแบบ Pyramid Structure ก็จะประยุกต์ใช้ Agile ได้ยาก
    • Agile เป็นแนวคิดที่พัฒนามาจากบริษัท Software Development เลยเหมาะในการใช้พัฒนา Tech Product มากกว่า แต่ไม่ได้หมายความว่าจะประยุกต์ใช้กับงานแบบอื่นไม่ได้ (ที่บริษัทก็มีการประยุกต์ใช้กับทีมที่ทำงานด้าน Marketing เหมือนกัน) เพียงแต่ต้องใช้เวลาและต้องประยุกต์จากหลักการเดิมไปค่อนข้างเยอะ

    หวังว่าจะได้รับประโยชน์ไปกันบ้างครับ อย่าลืมนะครับว่า Agile ไม่ใช่รูปแบบหรือวิธี แต่เป็นแนวคิดหรือหลักปรัชญา ขึ้นอยู่กับว่าแต่ละคน แต่ละองค์กรจะเอาไปประยุกต์ใช้อย่างไร ใครทำงานในบริษัททีใช้ Agile มาแชร์กันได้นะครับ ว่ามีการประยุกต์ยังไง และมีข้อดี ข้อเสีย อะไรบ้าง เพื่อที่จะได้เป็นประโยชน์กับผมและผู้อ่านท่านอื่นๆ ต่อไปครับ

    ติดตามข่าวสารจาก Brand Inside ได้จาก Facebook ของเรา