To achieve the agility in our projects, we leverage the Scrum framework. The best traits that we see in scrum are being lightweight and simple to understand. It is true that Scrum is hard to master, however, since we adopted it from the day we started the company, we are highly motivated about using it to our benefit. Please spend a bit of time to go over the Scrum Guide for more detailed information on Scrum.

Scrum Values

  • Courage: People are encouraged to speak their minds both on projects that they participate as well as at town hall meetings. We focus on empowering individuals to make their own decisions in order to be more successful on delivering high quality product.
  • Focus: Everyone within the company focuses on meeting the goals of the Sprint and Scrum team. This would be on both delivering the high value as well as meeting the standards of team and company.
  • Commitment: People within the company are committed to achieve both company and scrum team goals.
  • Respect: People are independent and it is being respected by everyone within the team.
  • Openness: The scrum team agrees to be open to each other in order to create an environment for self development as well as for a better product.

Scrum Events and Artifacts

  • Sprint : Every project team works on their time framed sprints. Timebox might differ from team to team, however, it must be boxed.
  • Sprint Planning : Each team has their own planning meetings with Product Owners, Scrum Masters and Development Teams. This will be the agreement meeting on what will be achieved in the next sprint.
  • Daily Scrum : Each team would have their scheduled meetings everyday for updating their team members on what has been done the previous day and what is the plan for the current day. Attendance to Daily Scrum is crucial and the punishment for not attending the meeting more than twice within a month is decided by the team. (Baklava is highly encouraged.)
  • Sprint Review : Held at the end of every sprint to show the increment to the PO as well as the stakeholders. Each time are required to have this meeting.
  • Sprint Retrospective : This meeting is regarded as the low priority by most people using Scrum, yet, this is one of the most prioritized events that we want teams to be held. This meeting helps teams to grow and understand their weaknesses as well as their strengths.
  • Backlog Refinement(Grooming) : This meeting is recommended yet, not mandatory. The owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

This event ends up producing the artifacts that can be seen below:

  • Product Backlog
  • Sprint Backlog
  • Increment


There are two concepts that we apply in scrum in order to achieve transparency during the scrum and within artifacts.

  1. Definition of Ready

  2. Definition of Done

Acceptance Criteria can be used to leverage those two concepts.

How to Scrum?

At this point it is should be clear that all the things mentioned above are the things that we require from our project teams to apply to their projects. However, the time limits, number of project members are based on different requirements such as:

  • Team structures
  • Team size
  • Clients needs
  • Project complexity

Scrum Methodology Requirement Levels


The requirement levels diagram below summarizes what are the responsibilities for each entity as well as where the requirements fall under scrum.

Subsections of Scrum

Sprint Planning

Frequency: Once per sprint

Meeting length: 2 - 8 hours

What is Agile Planning?

Agile planning is focused on getting the answers to simple questions like

  • What is to be built?
  • When will it be completed?
  • How much will it cost and who should be involved?

The project managers also explore hidden dependencies for various activities to minimize the idle time and optimize delivery period. Agile planning revolves around measuring the velocity and efficiency of an Agile team to assess when it can turn the user stories into processes, production-ready software, and quality product delivery. The ultimate goal of Agile planning is to have a clear picture of project vision, production roadmap with sprint schedule, and business interests. To simplify the things, Agile planning can be stipulated of different levels;

  • product vision
  • product roadmap
  • release
  • iteration
  • daily commitment.

Level 1: Agile Planning For Product Vision – Five Tips

Agile planning starts with product vision creation ensuring that strategies are aligned properly and the development team spends its time on creating the right valuable product. The product vision guides the team members for the shared goal like a lighthouse. The product vision statement tells about ‘how the product supports organization’s strategies.’ You can simplify the process of Agile product vision development by making it a four-step exercise – development, drafting, validation, finalizing. The following five tips will help you to get the most out of it:

  • Product vision should deliver the unique feel of ownership to keep you motivated.
  • Validate your product vision with all the stakeholders, Scrum team members, users etc.
  • Develop the product vision iteratively & incrementally with the scope to make it better over time.
  • The product vision pitch should address all the key concerns of different stakeholder groups pertaining to quality, product goals, competition, longevity and maintenance needs etc.
  • Focus your product vision on the values for users and customers not merely on the most advanced technology.

Level 2: Agile Product Roadmap Planning– Five Tips

An Agile product roadmap is a plan that describes the way the product is likely to grow; it also facilitates for learning to change. To succeed in Agile management, you need to have a goal-oriented roadmap as it provides crucial information about everyday work by the team. As a powerful Agile management tool, it helps to align all the stakeholders and to estimate sufficient budget for quality product development as per schedule. Creating effective roadmap is often a challenge because changes occur unexpectedly in an Agile environment; however, the following five tips will help you plan the most effective roadmap:

  • Do all the necessary prep work including describing & validating the product strategy. To know more about ‘Product strategy in the Agile world’, visit - .
  • Focus your product roadmap on goals, benefits, objectives, acquiring customers, removing technical debt and increasing engagement etc.
  • Let your product roadmap tell a coherent story about the likely development of a product. To simplify the task, you can divide the product roadmap into two parts- internal product roadmap and external roadmap. The internal product roadmap is focused on development, service, supporting groups, marketing, sales etc; while, the external roadmap is focused on prospective & existing customers.
  • Keep the product roadmap simple and realistic to make the features understood by everyone concerned.
  • Make your product roadmap measurable; so, think twice before adding timelines and deadlines.

Level 3: Release Planning – Five Tips

In Agile landscape, the release is a set of product increments released to the customer. The release plan defines how much work your team will deliver by the mentioned deadline. Release planning is the collaborative task involving Scrum master (facilitates the meeting), Product owner (shares product backlog view), Agile team (provides insights into technical dependencies & feasibility) and Stakeholders (the trusted advisors). The following five tips will help you in effective release planning:

  • Focus on goals, benefits, and results.
  • Take dependencies and uncertainties into account.
  • Release early but don’t release just for the sake of scheduled releasing.
  • Only release the work that is ‘Done’. To know more about ‘Definition of Done (DoD)’ in Agile, plz visit - .
  • Each release process has the scope for betterment. Continuous release process improvement helps you deliver more values for the product.

Level 4: Iteration Planning - Five Tips

The iteration planning is done by holding a meeting, where all the team members determine the volume of backlog items they can commit to deliver during the next iteration. The commitment is made according to the team’s velocity and iteration schedule. The following five tips will help you in effective iteration planning:

  • Span the iteration planning meeting maximum up to 4 hours.
  • The planning meeting is organized by the team and for the team; so, everyone should participate.
  • Avoid committing anything that exceeds the historical team’s velocity.
  • Keep time for ‘retrospectives’ in the past sprints before planning for the next one. To know more about ‘Agile retrospective’, visit -
    Follow the four principles prepare, listen, respect & collaborate

Level 5: Daily Commitment Planning– Five Tips:

Like many other planning activities for Agile management, the daily commitment planning also needs the synchronized partnership of teams. The daily planning meeting is focused on completing the top-priority features. The 15-minute standup meeting facilitates face-to-face communication on individual’s progress and impediments if any. The following five tips will help you in progress-oriented daily commitment planning:

  • Keep it around the task board.
  • Start on time regardless of who is present or not.
  • Let each team member go through the questions like - what he did yesterday, what is his plan for today, and, is there any impediment?.
  • Use ‘Parking Lot’ for the unresolved issues. The purpose of daily Agile-Scrum planning is to let the team members know about ‘being done’, ‘needs to be done’ and ‘hindrance if any’. Anything out of this scope should be listed in ‘Parking Lot’ to be dealt later.
  • Do preparation ahead of time. The team members should know ‘what they need to share’.

Daily Scrum Meeting

Frequency: Daily

Meeting length: 10 - 15 minutes

Scrum meetings are a part of agile meetings, or scrum ceremonies, where all team members can sync up on the work they did in the last 24 hours, and go over what’s on deck for the next 24 hours.

Daily Scrum Meeting Checklist


Is there anything preventing contributors from getting work done? Things to bring up here might be technical limitations, departmental and team dependencies, and personal limitations (like vacations booked, people out sick, etc.).

What did you do yesterday?

This is a quick rundown of what got done yesterday (and if anything didn’t get done, then why). This isn’t the time for each person to run down their whole to-do list – they should focus on the large chunks of work that made up their deep focus time, and the activities that are relevant to your team as a whole.

What are your goals for today?

Here, each team member will say what they want to accomplish – in other words, what they can be held accountable for in tomorrow’s daily scrum meeting.

How close are we to hitting our sprint goals? What’s your comfort level?

This agenda item will help the scrum master get an idea of how the team is feeling about how their day-to-day activities are impacting overall goals for the team, and how contributors are feeling about the pace of the sprint.

What to avoid in your daily scrum?


Being late for any meeting is disruptive, but it’s particularly distracting when the meetings are only 10 minutes long. Hold your team accountable for being on time, every time.

Monopolizing the conversation

Giving each team member the opportunity to talk is hugely important. Reinforce this at the start of each scrum if you find that certain team members have a tendency to ramble on.

Over-formalizing the process

Don’t over-complicate your scrum meetings. Keep the agenda the same each time you meet, and make the technology for meeting consistent. Daily scrum meetings involve less than 10 minutes of meeting prep, max.

Other daily scrum meeting tips:

  • Hold your daily scrums in the morning and at the same time each day
  • Do you daily stand-ups in person (standing up) where possible. If that’s not possible, use a reliable and consistent tool for communicating remotely (we love a good Slack Bot for this).
  • Let the team lead the conversation
  • Be a time cop and don’t let your stand-ups run more than 10 minutes

Referenced from here.

Sprint Review

Frequency: Once per sprint

Meeting length: 1 - 4 hours

Sprint Review or a Demo?

Many of those practicing Scrum mistakenly call the Sprint Review a Demo. Is it just a matter of terminology? From my point of view, the Sprint Review is the most underestimated Scrum Event, and for many companies, its potential is yet to be revealed. It is true that the Demonstration or Demo is an essential part of the Sprint Review, but it isn’t the only one.

The Sprint Review is much more than just a Demo.

Let’s find out why.

Who attends the Sprint Review

The Scrum Team and stakeholders (users, other teams, managers, investors, sponsors, customers, etc.) One could say that we invite the whole world to the Sprint Review and this is absolutely true.

How the Sprint Review Is Conducted:

  • The Product Owner opens the meeting and tells the attendees what the Development Team completed during the current Sprint (what has been “Done” and “not Done”).
  • The Development Team demonstrates the “Done” functionality (Demo), answers the questions and discusses problems they met on their way.
  • The Product Owner discusses the current state of the Product Backlog, marketplace changes, and forecasts the likely release dates.
  • The attendees collaborate on the Product Backlog Items, which can be completed during the next Sprint. Thus, the stakeholders get a shared understanding of the future work.
  • A review of the budget, timeline, potential capabilities follows.

The Opportunity To Inspect And Adapt.

Sprint is one of the five official Scrum Events and is an opportunity for the Scrum Team to practice empiricism. Here is a short summary of what we inspect and adapt during the Sprint Review.

Inspect: Sprint, Product Backlog, Increment, Marketplace, Budget, Timeline, Capabilities.

Adapt: Product Backlog, Release Plan.

Inspecting Is Much More Than Just An Increment.

The Sprint Review is not just about product demonstration, it is an inspection of the completed Sprint, the Product Backlog and the marketplace. Also, it is a place for reviewing budgets, timeline and capabilities. Each Sprint is an important risk mitigation tool and the Sprint Review is a decision point for the Product Owner.

Each Sprint can be the last one. The Product Owner makes a formal decision regarding financing the next Sprint during the Sprint Review.

Here are some decisions that can be formally made:

  • Stopping/Pausing the development
  • Financing the next Sprint
  • Adding team(s) with an assumption that it will speed up the development
  • Releasing Increment (can be done anytime during the Sprint)

Is My Sprint Review Good Enough?

Scrum is based on iterative and incremental development principles, which means getting feedback and making continuous updates to the Product Backlog. Unfortunately, teams often forget about it.

The Sprint Review is a great tool for getting feedback, while the number of changes to the Product Backlog after the Sprint Review can be an important indicator of how healthy your Scrum is.

Why Many Scrum Teams Don’t Go Beyond Demo

Many teams/companies underutilize the entrepreneurial spirit of Scrum and its concept where the Product Owner is a mini-CEO of the Product. Very often, stakeholders attend only the Increment demonstration (usually done using a projector) with few questions asked and then everybody leaves shortly afterwards. This may happen for several reasons:

  • The Product Owner doesn’t actually “own” the product, cannot optimize the ROI or make strategic decisions about the product, and is, in fact, a Fake Product Owner (FPO). During the Sprint Review, stakeholders (with actual Product Owner among them) often “accept” the Scrum Team’s work.
  • The company’s business and development departments continue to play the “contract game” with predefined scope and completion dates. In this case, the Sprint Review inevitably becomes a status meeting.
  • Superficial Scrum implementation at the company.
  • The Product Owner doesn’t collaborate enough with stakeholders.
  • This is a case of “fake Scrum”, when the Scrum Team handles only a part of the system with inputs and outputs and not the real product. There is nothing to show and nothing to give feedback on.

Good Sprint Review Practices

  • An informal gathering with coffee and cookies that looks more like a meetup, often held as an Expo or a Review Bazaar.
  • The Product Backlog is updated after/during the Sprint Review.
  • The meeting is often attended by the end users.
  • The Development Team communicates directly with end users and stakeholders and gets direct feedback from them.
  • The “Done” product is showcased on workstations where the stakeholders can play with the new functionality.

Signs of An Unhealthy Sprint Review

  • A formal/status meeting.
  • The new functionality is demonstrated only in a slide show.
  • The Product Owner “accepts” the work completed by the Development Team.
  • The Development Team isn’t (fully) present.
  • Neither are stakeholders and/or end users.
  • The demonstrated functionality does not meet the Definition of “Done”.
  • The Product Backlog is not updated. The Scrum Team works with a predefined scope.
  • The stakeholders “accept” the completed work from the Product Owner.

The Bottom Line

Well, I wrote quite a lot. Let’s sum it up.

  • The Sprint Review is more than just a Demo. The Sprint Review is a place to discuss the marketplace changes, examine the completed Sprint as an event, update the release schedule, discuss the Product Backlog and the possible focus for the next Sprint. This is where the dialog between the Scrum Team and the stakeholders takes place and feedback on product Increment is obtained.
  • The number of changes to the Product Backlog can be an important sign of how healthy your Scrum is.

Sprint Retrospective

Frequency: Once or twice per sprint (Not mandatory)

Meeting length: 1 - 4 hours

Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. This is the opportunity for the Scrum Team to improve and all member should be in attendance.

During the Sprint Retrospective

The team discusses:

  • What went well in the Sprint?
  • What could be improved?
  • What will we commit to improve in the next Sprint?

Expected Output

The Scrum Master encourages the Scrum Team to improve its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Backlog Refinement (Grooming)

Frequency: Once or twice per sprint (Not mandatory)

Meeting length: 2 - 4 hours

Backlog refinement (formerly known as backlog grooming) is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

Backlog Refinement Checklist


Items should be discussed and prioritized based on customer / market needs.

Decomposition of Items

The issues should be completed within a sprint, thus, if there are any issues that are not

Cleanup of Deprecated Items

Some of the issues may be deferred due to change of requirements or necessity of that feature, thus, cleanup of the backlog items can be done here.

What to avoid in your grooming?


This has its’ own meeting, attendees should not discuss the sprints that these items will be developed.

Old Issues - Completed Sprints

This meeting is to clean the backlog, completed items are not in scope of this meetings.

Performance and Forecasting

These can be done during retrospective, this has nothing to do with the grooming meetings.

Other grooming tips:

  • PO can discuss priorities and requirements with stakeholders before the meeting.
  • Weight (or any other measurement types) can be added during this meeting.
  • Not everyone is needed in this meeting.

Referenced from here and here


Frequency: Daily

Duration: 1 - 4 weeks

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.


Subsections of Concepts

Definition of Ready

What is Definition of Ready?

Definition of Ready is the properties required for a task to be started. It has to be clear, open and transparent.

What are the perspectives that have to be covered?

  • User Story / Task
  • Sprint
  • Test

User Story / Task Perspective

User story has to cover all necessary items which are based on INVEST principles.

Invest principles items;

  • Independent(of all others)
  • Negotiable(not a contract for specific feature)
  • Valuable(a vertical slice - feature ownership)
  • Estimable(to decent approximation)
  • Small(enough to fit in a single iteration)
  • Testable(even if the tests don’t exist yet)

Accept an user story is ready, below items have to covered by the user story;

  • The conditions of satisfaction have been fully identified for the story.
  • The story details have to be understandable by the all scrum team.
  • The story has been estimated and is under a certain size which is defined by the scrum team.
  • The team’s user interface designer or Product Owner has mocked up, or even fully designed, any screens affected by the story.
  • All external dependencies have been resolved, whether the dependency was on another team or on an outside vendor.
  • Test environment or devices which is related the story, have to be ready.

Sprint Perspective

  • Prioritized sprint backlog
  • Defects, user stories and other work the team has committed to are contained in the sprint backlog
  • No hidden work, all backlog items have to be detailed enough for next sprint.
  • All team members have calculated their individual capacity for the sprint
  • All users stories meet the definition of Ready.

Test Perspective

  • Implementation or Work Item;

    • Has to be delivered as an increment.
    • Has to cover all definition of done rules.

    Test environment have to be ready for related item.

How the Definition of Ready should be?

Definition of Ready may not be covered all items which ared listed above. Project members have to select necessary items for their and customer needs. The items can be extended and teams can add their own custom rules to team’s definition of ready list. The most important rule is, each team member has to be beware of the definition of ready and follow the rules.

Definition of Ready Example

  • The conditions of satisfaction have been fully identified for the story.
  • The story details have to be understandable by the all scrum team.
  • The story has been estimated and is under a certain size which is defined by the scrum team.
  • Prioritized sprint backlog
  • Defects, user stories and other work the team has committed to are contained in the sprint backlog
  • Product backlog items have to be approved by the product owner.

Definition of Done

What is Definition of Done?

The Definition of Done is an agreed upon set of items that must be completed before a project, user story, test case, deployment steps etc. can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.”

What are the perspectives that have to be covered?

  • Development
  • Test
  • Deployment
  • Documentation

Development Perspective

  • Code have to be written by following defined code formatting.
  • Comments have to be added to explain complex solutions.
  • Implementation have to be complete within defined code complexity levels
  • Any other third party solution(Library, Framework etc.) which endangers CDP, should not be used in implementation.
  • Before committing implementation, written code/solution have to be reviewed by at least other one developer.
  • If implementation needs integration with another module and the module has not implemented during implementation, mock data or mock module should be used to test implementation.

Test Perspective

  • Unit tests have to be written by developer.
  • All edge cases have to be tested by the developers.
  • If it is needed, to keep CI/CD pipeline alive, necessary updates have to be done on CI/CD configuration for tests.

Deployment Perspective

  • Implementation has to be tested by the testers before deployment.
  • Before deployment, tester has to complete all regression tests to be sure that implementation is not effects any other modules.
  • Before deployment, all automated tests have to be run. If test coverage below defined coverage percentage, implementation have to be rolled back.
  • If implementation uses third party solutions/app, the packages should be added for deployment environment(Docker or Yocto scripts)

Documentation Perspective

  • If implementation steps have complex solutions, developers have to write a document or update existing development documents to explain their solutions properly.

How the Definition of Done should be?

Definition of Done may not be covered all items which is listed above. Project members have to select necessary items for their and customer needs. The items can be extended and teams can add their own custom rules to team’s definition of done list. The most important rule is, each team member has to be beware of the definition of done and follow the rules.

Definition of Done Example

  • Code has to be written by following defined code formatting.
  • Comments have to be added to explain complex solutions.
  • Implementation has to be complete within defined code complexity levels
  • Change log has to be updated after each completed product backlog item.

Acceptance Criteria

Acceptance criteria are the conditions that a software product must meet to be accepted by a user, a customer, or other system. They are unique for each user story and define the feature behavior from the end-user’s perspective. Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.

Main purposes of the Acceptance Criteria is clarifying the stakeholder’s requirements.

Some of the criteria are defined and written by the product owner when he or she creates the product backlog. And the others can be further specified by the team during user stories discussions after sprint planning.

  • Acceptance Criteria have to be written before development starts.

  • Acceptance Criteria shouldn’t be too narrow.

  • Acceptance Criteria have to be achievable in one sprint iteration.

  • Acceptance Criteria have to be measurable and not too broad.

  • Acceptance Criteria shouldn’t contain Technical Details

  • Acceptance Criteria have to be understandable by all Scrum Team members

  • Acceptance Criteria have to be testable

Acceptance Criteria should contain;

  • Feature scope detalization

    Acceptance Criteria define the boundaries of user stories. They provide precise details on functionality that help the team understand whether the story is completed and works as expected.

  • Describing negative scenarios

    Acceptance Criteria may require the system to recognize unsafe password inputs and prevent a user from proceeding further. Invalid password format is an example of a so-called negative scenario when a user does invalid inputs or behaves unexpectedly. Acceptance Criteria define these scenarios and explain how the system must react on them.

  • Setting communication

    Acceptance criteria synchronize the visions of the client and the development team. They ensure that everyone has a common understanding of the requirements: Developers know exactly what kind of behavior the feature must demonstrate, while stakeholders and the client understand what’s expected from the feature.

  • Streamlining acceptance testing

    Acceptance criteria are the basis of the user story acceptance testing. Each acceptance criterion must be independently testable and thus have a clear pass or fail scenarios. They can also be used to verify the story via automated tests

  • Feature estimation

    Acceptance criteria specify what exactly must be developed by the team. Once the team has precise requirements, they can split user stories into tasks that can be correctly estimated.

Acceptance Criteria Template for User Story

Scenario the name for the behavior that will be described
Given the beginning state of the scenario
When specific action that the user makes
Then the outcome of the action in “When”
And used to continue any of three previous statements


User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.

Scenario: Forgot password
Given: The user has navigated to the login page
When: The user selected forgot password option
And: Entered a valid email to receive a link for password recovery
Then: The system sent the link to the entered email
Given: The user received the link via the email
When: The user navigated through the link received in the email
Then: The system enables the user to set a new password