Hany Ouf

User Story  - A user story is a description of a requirement from a user's point of view. - Requirements are captured on a piece of card, 3 by 5 inches in dimension. -Each User Story should fullfil The INVEST Principle: Independent Each uses story should be self-contained from all the other user stories in the product backlog. Why That to avoid getting the project in a situation where you cann't start a user story owing to the fact that this story have a dependency on another story. Negotiable Negotiable means that all the team members with different roles, are able, at all times, to negotiate what is on a user story by having a discussion with the product owner. Why To make sure that the right decision is made, on all dimensions (Technical, Bussiness, Testing, Data...etc). Valuable Valuable means to make sure that any user story actually really has a value. Why To make sure that nothing is done unless it's really going to give a return on investment

Product  Backlog In agile scrum, a product backlog is a prioritized list of features that has short descriptions on all the various functionalities desired in a product. Unlike a requirements document, with scrum, there is no need to struggle with producing a lengthy product backlog at the beginning of the project and then leave it on your shelves to collect dust. Basically, the PO, scrum master and scrum team brainstorms on the work needed to finish the product/project and then puts it on the product backlog, in priority order. This initial product backlog can be used for the first sprint but the team continues to make the necessary changes to it as they learn more and more about the product and its customers. Generally, a scrum product backlog contains anything relating to the product:  ✓    Features (New features (functional and non-functional requirements) or product extensions to address new opportunities or markets, or features requested by customers or internal stake

The Scrum Events: Sprint planning meeting:   (Time Box: 8 hours for a one month sprint). Planning Meetings are held at the beginning of each sprint which lasts a maximum of 8 hours (for 1 month sprints). It is attended by product owner, scrum master and scrum team. The PO  submits and describes the prioritized product backlog and explains to the team about the sprint goal and product backlog’s top items. The team  agrees on which prioritized items to complete during the upcoming sprint and then shifts these items from the product backlog to the sprint backlog. Daily scrum meeting : (Time Box: 15 minutes) Every day, during the sprint, the scrum master, scrum team and or product owner (optional) must attend a daily scrum meeting of less than 15 minutes. During these day to day scrum meetings, the team members  talk about what they worked on the previous day ,  what they’ll work on that day  and  identify any setbacks to progress . This daily scrums synchronize the sc

What is scrum Scrum is a very popular framework for implementing agile project management. Although some people think that agile and scrum is the same thing, this is wrong. While there are many frameworks for implementing agile, scrum is the most outstanding owing to its specific concepts and practices categorized into roles , timeboxes and artifacts . Generally, the components of the scrum framework are: 1.  Three roles : Product owner, scrum master and scrum development team 2.  Sprints : A project iteration of less than a calendar month 3.  Scrum events/ceremonies : Sprint planning meeting (what and how meetings), daily scrum meetings, sprint review meeting and sprint retrospective meetings. 4. Scrum artifacts a) Product Backlog: a prioritized backlog with end user requirements; the product owner is responsible for this b) Sprint backlog:  Elected items from the product backlog. It’s like a mini-plan for achieving the sprint goal and delivering the prod

What is Agile In a nutshell, agile is an umbrella term for a set of frameworks and methods.  These use iterative time-boxed approaches and focus on building products incrementally from the beginning of a project rather than delivering it all at once at the end. Agile basically encourages frequent inspection and adaptation plus teamwork, accountability and self-organization . Moreover, the engineering behind agile projects allow speedy delivery of first-class products and their business approach aligns development with company goals and customer needs . Agile often works by breaking down projects into tiny user functionality bits called user stories , which are prioritized and then continuously delivered in short cycles (mostly 2 weeks) called iterations . Refrences: Paul VII. Agile Product Management: User Stories:  How to capture, and manage requirements for Agile Product Management and Business Analysis with Scrum (scrum, ... development, agile software development)

An  edge case  is a problem or situation that occurs only at an extreme (maximum or minimum) operating  parameter .  For example, a function that divides two numbers might be tested using both very large and very small numbers. Acceptance  Criteria template: |  A <role> should <see/be able to do> the following:  |     - <AC1>  |     - <AC2> |     - <AC...>  |   |  Edge Cases:  |    - <EC1>  |    - <EC2>  |    - <EC...> Example in a user story: Refrences: http://pashunconsulting.co.uk/blog/productbacklog.html https://en.wikipedia.org/wiki/Edge_case Paul VII. Agile Product Management: User Stories:  How to capture, and manage requirements for Agile Product Management and Business Analysis with Scrum (scrum, ... development, agile software development) (p. 31). Pashun Consulting Ltd.. Kindle Edition. 

Acceptance Criteria Definition 1 : “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” ( via Microsoft Press ) Acceptance Criteria Definition 2:  “Pre-established standards or requirements a product or project must meet.” ( via Google ) My Own opinion: The second definition may be considered the main definition, "Acceptance Criteria" is nothing but the usual functional, and non-functional requirements. The purpose of acceptance criteria is to articulate precisely when the user story is 'done' from the product owner's perspective. They should translate into 'acceptance tests’ that a tester (or quality assurance tester) can use to verify the quality of a feature. A tester should be involved in writing them, but it is a product owner's responsibility to produce them. Agile business analysts are very helpful in assisting product owners and extracting the right information for user st