1. A GILE SCRUM Presenter Name: Eng. Rasha Farouk Presentation Date: 4 th October 2015

2. Main Topics Pleasing Your Customer. Gathering Requirements. Agile Software Development.

3. Pleasing Your Customer

4. Ultimate goal of software development Make your customer happy solving your customer’s problem by delivering – what is needed – on time – on budget

5. This is NOT easy Important: Need to have a clear idea of who your customer is!! Software is NOT Guesswork – You need to keep the customer in the loop to make sure you’re on the right path even when you’re SURE you know what the customer wants

6. Great Software Delivers: What is needed – Requirements On Time – Project Planning On Budget – Project Management

7. Gathering Requirements

8. Knowing what the customer wants. How?

9. Requirements Gathering Brainstorming User Stories Planning – Estimation Game By Follow these steps:

10. Impose Structure. – Identify all of the different things the system has to do. A requirement is: – A single thing that the software has to do. – Written in User’s Language. Translate Entire Problem Statement. – Title: – Description: Requirements Gathering-1:

11. Return to customer and ask questions: – Did I get this right? – What did you mean by…? – Gather more requirements. – Is this really all of the functionality that you need? – If we built all of this, what would you want in version 2.0? All this work will lead to new or clarified requirements Requirements Gathering-2:

12. Problem: Not Enough? – you feel that you just don’t have a good grasp on the big picture. – This can be especially true if “customer” ≠ “end user” – Next step is to hold a brainstorming session with as many different stakeholders as possible. It also calls a “blue-sky session” Requirements Gathering-3:

13. Goal: get stakeholders to generate tons of candidate requirements; not everything will make it into the final system Things to Avoid – The Silent Tomb: Leave job titles at the door, people should not feel afraid to speak up just because the boss is there – Criticizing people rather than ideas – Developer jargon “NOT ‘AJAX’ but ‘rich user interface’” Bluesky Session “Brainstorming session”:

14. Transform requirements gathered so far into user stories. – A user story describes how the user interacts with the software you’re building. – It should be written from your customer’s perspective and describe what the software is going to do for the customer. – User stories are essentially informal use cases. Next? User Stories - 1

15. SHOULD – describe one thing the system should do for the customer. – be written using language that the customer understands. – be written by the customer !! – be short. No longer than three sentences. SHOULD NOT – be a long essay – use technical terms unfamiliar to the customer – mention specific technologies (save those for design) Next? User Stories - 2

16. At some point during the requirements gathering process, the customer will ask: – How long will all of this take to develop? You need to supply a project estimate which will be the sum of the estimates for your user stories So, now you need to supply estimates for each user story How do we come up with this estimate?

17. Planning Poker – 1 Planning - 1

18. The zero card means “this story is already done” or “this story is pretty much nothing, just a few minutes of work”. The question mark card means “I have absolutely no idea at all. None. ” Should be rare. If this card is used too often, the team needs to discuss the stories more and try to achieve better knowledge spread within the team. The coffee cup card means “I’m too tired to think. Let’s take a short break.” Addresses the problem in which two or more team members come up with wildly different estimates for a story i.e. when a single user story generates estimates of say “3 days”, “2 weeks”, and “3 months” from three different developers. The underlying cause for these different estimates is assumptions; what did you assume was true or not true about the project to generate the number that you did? Planning - 2

19. Place a user story in the middle of the table. Each team member thinks about the story and forms initial estimate in their heads. Each person places the corresponding card face down on the table; note: estimate is for entire user story. Everyone then turns over the cards at the same time. The larger the differences between the estimates, the less confident you are in the estimate, and the more assumptions you need to highlight and discuss. So, the next step in planning poker is: – Put assumptions on trial for their lives – Have each team member list the assumptions they made and then start discussing them? – Again, you need to criticize the assumption not the person – Goal is to get agreement on what assumptions truly apply. Planning - 3

20. If the assumptions reveal a misunderstanding of the requirements, then go back to the client and get that misunderstanding clarified. Otherwise, start to eliminate as many assumptions as possible, then have everyone revise their estimates and play planning poker again to see if the spread has decreased. Your goal is once estimates cluster around a common number, assign that number and move to the next story. Planning - 4

21. Your life cycle is thus – Talk to customer: clarify misunderstandings, assumptions. – Play planning poker. – Clarify assumptions, possibly by returning to step 1. – Come to a consensus estimate for the user story. Do this until all user stories have a consensus estimate assigned. Things to watch out for – Big estimates == bad estimates If the story is too big; decompose; try again. Ideal iteration is 20 work days (1 month).

22. Requirements Life Cycle

23. Standup Meeting A daily meeting used to – keep the team motivated and aware of progress (or not) – keep your board up-to-date – highlight problems early It should – Track progress and update tasks. – Discuss what happened yesterday and plan today’s activities. – Bring up issues, and last between 5 and 15 minutes “Its so short, no one has time to sit down”

24. Agile Software Development

25. Why software projects fail? Unrealistic Schedules. Inappropriate Staffing. Changing Requirements During Development. Poor-Quality Work. Believing in Magic.

26. Agile Scrum

27. Prepare Scrum Project Populate Product Backlog Estimate Backlog Using Planning Poker Prioritize Backlog Populate Release Backlog Populate Sprint Backlog SPRINT Sprint Demo Sprint Retrospective

28. Prepare Scrum Project - 1 The term scrum comes from the game of rugby and a short for scrimmage derived from scrimmage. Old in the context of software development scrum is a method of project management. The purpose is to keep the focus on delivering the highest business value to stakeholders in the shortest time possible.

29. Prepare Scrum Project - 2 There are three core rules: – the product owner:  represents the stakeholders and is the voice of the customer.  The product owner is accountable for ensuring that the team delivers value to the business. – Team members :  are responsible for delivering potentially shippable products.  the team is composed of three to nine individuals with cross functional skills who do the actual work that is analyze designs develops test document et cetera. – Scrum master :  scrum is facilitated by a scrum master who is accountable for removing impediments to the ability of the team to achieve the sprint gold and produce deliverables.  the ScrumMaster insurers that the Scrum process is used as intended.  and acts as the enforcer of a scrum rules. The core rules are the only ones who are committed to the project. In the scrum process there are a few other roles that may have stake in the product. These stakeholders do not have any formal role in the team and are only involved in the process infrequently.

30. Populate Product Backlog- 1 The product owner is responsible for: – writing requirements. – Defects. – Enhancement. – Features from the perspective of the end-user. The product owner needs the effort in capturing users stories but expressed desire needs and features other product to be built. Customers, stakeholders, business, IS and any derivative are invited to participate. The product owner writes the user stories and often does so in front of a stakeholder group. the collection of all these users stories is called the product backlog. This product backlog can be thought of as a wish list of the customer that will make the product great.

31. Populate Product Backlog- 2 The Scrum Master facilitates the process of populating the product backlog and when necessary helps that product owner author user stories. Team members can help contribute input to business or technical user stories. The actual order a the creation of user stories is not important. The goal is to have the backlog to conduct further planning and allow the team or teams to begin work.

32. Populate Product Backlog- 3 So how do we write user stories? A user story describes a single feature in terms of the user interaction. Specifies the role, requirement, and purpose of a chunk of functionality. They can often have the following format:

33. Populate Product Backlog- 4 User Stories can often have the following format:

34. Populate Product Backlog- 5 Example:

35. Populate Product Backlog- 6 In addition each user story has conditions of satisfaction. These conditions: – enable the team members to know when they have met the requirement for a user story. – these are not test cases but significant business acceptance criteria.

36. Populate Product Backlog- 7 In our example conditions of satisfaction could be:

37. Estimate Backlog Using Planning Poker - 1 This product backlog is the customer's wish list. That will make the product great. The product owner would like to have created or built estimates in the product backlog for work. Several valid estimation techniques are available including expert judgment proxy estimation based on past projects. All these techniques require that we choose a unit of estimation and measurement.Story points are among the most effective units have estimation. Story points tell us how big a user story is relative to others either in terms of size or complexity.

38. Estimate Backlog Using Planning Poker - 2 When it comes to choosing numbers to represent the sizes. Sequence works will be 0 1/2 one to 3 5 8 13 20 40 100. Story points are created by and are specific to the team that estimated them and will likely include a degree of complexity. That is understood only by the team doing the estimating. The estimation process will be facilitated by the Scrum Master. The product owner read too the user story together with the conditions have satisfaction to the team and begins a conversation to put the user story into context. the product owner will answer questions,clarify expectations and provide explanations about what exactly the story entails. The Scrum Master can read these details as discussions proceed and jot down things to be read.

39. Estimate Backlog Using Planning Poker - 3 Every team member pulls out our estimate card. So no one else can see it after everyone has picked their estimate card. They are revealed at the same time. If everyone is holding the same number. This established as the relative estimate of the story. If estimate cards are different we discuss it. Let's look at that example, our team members holed up three five and 13 at this point. We want to hear from who select 3 and 13 why if three and why if 13. Anyone from the team who will participate in completing the story can talk and ask questions. The team member holding the 13 could say I am developer and this is going to be really hard to code. I need to set up a database set up the environment and so on. The team member holding the three could say you are right and I'm going to come up in my estimates. After everyone has a chance to talk, each team member picks a number again from the card deck. At once the cards are revealed. This time the team members holed up 8, 8 and 13. At this point, the Scrum Master will ask the team member holding a 13 to explain why a 13? if agreeable to the team, every one switches to 13.

40. Estimate Backlog Using Planning Poker - 4 This is not a vote and the majority doesn't rule team members keep going until the consensus is reached. Once the team agrees on the estimate, the Scrum Master will mark the user story card with the estimate number and the product owner will put it back on the backlog in no particular order. One challenge with a relative estimation is how to get started and which story to pick first.

41. Prioritize Backlog - 1 Priorities a product backlog is the one beast that has been elaborated on extensively in the s/w industry. After the team completes populating and estimating the product backlog, the next step is to determine a logical sequence to build or implement the user stories. The product owner is responsible for prioritizing the product backlog and ensuring that the team delivers to the customers.

42. Prioritize Backlog - 2 There are many factors that drive the product backlog prioritization. The product owner will group the stories into high, medium and low categories. Arriving at their correct set of prioritization is not easy. It takes a lot of negotiations with different stakeholders and users have the systems to arrive at the final priority list. There are several techniques. The product owner will organize the user stories in priority order.

43. Prioritize Backlog - 3 Ranking the highest priority stories first, medium and low priority stories can remain in the backlog without being ranked. The Scrum Master facilities the process by working closely with the product owner and does not directly prioritize the backlog. Team members are typically observers and may offer input if requested.

44. Prioritize Backlog - 4 A good product backlog has the following characteristics: – it is prioritized to ensure that the team builds the most important features first. – It is estimated by the team to give the product owner clarity and enabling him to answer questions such as "when will these stories be done?“ – It includes all the work necessary to complete the project. – It is constantly changing and involving to reflect the current realities above the project.

45. Populate Release Backlog The product owner is responsible for: – Planning and populating the release backlog – To ensure that the team delivers to the customer the release backlog. – To ensure that the team delivers to the customer the most valuable functionality first. the product owner takes input from stakeholders and business to plan the release. Team members provide contextual input but only upon request from the product owner.

46. Populate Sprint Backlog - 1 The product owner prioritizes the release backlog prior to the sprint planning exercise during spring planting. The Scrum team makes a commitment to the product owner to implement the user stories during the sprint. The Scrum Master facilitates the process of planning the sprint and ensures the team does not pull more user stories into the sprint backlog. If it exists the Scrum team moves the agreed sprint user stories to the Sprint backlog. team members ask clarifying questions to the product owner when necessary to further understand the details regarding the user story. And the scrum Master facilitates the team and product Owner discussions.

47. Populate Sprint Backlog - 2 Team members can nominate when applicability specific technical user stories that help the project progress forward and communicate these technical needs and their importance to the product owner once a sprint has started. The product owner may not add or change anything to the sprint backlog The Scrum Master protects the team from interference from outsiders while working within the Sprint. If the team indicates that it has excess bandwidth during the Sprint, the product owner may suggest to the team which additional user stories to pull.