gtFace: Agile Scrum
- 1. Kliknij, aby edytować styl wzorca podtytułu vContact: | www.gtFace.com | info@gtFace.com | (+353) 851 261 081 Agile Process
- 2. Because we are interested only in the success of the customer. SCRUM ensures control at each stage of the works, full transparency of the project and close cooperation with the customer. We know that the requirements defined in contracts often prove inadequate or unnecessary: we are not afraid of changing them. We are interested in a product that meets the customer’s requirements, which is not always the same as “compliant with the documentation”. Agile approach is the success of our customer. The success of our customer is also our success. Why we choose SCRUM.
- 3. The “big picture” is a multi-level presentation of the requirements towards the system that is to be created. This is the foundation of our understanding of: who will use it and what for, whether it will communicate with other systems and, if yes, with which ones, what are the most important business needs that the system will satisfy. The general presentation of the system has a significant impact on the posterior selection of the most important features and their assessment. An example of a requirement phrased as a User Story: Asthe owner of a bank account The project pricing is carried out by determining the level of complexity of individual requirements. Our evaluation of particular stories is based on the knowledge and experience gained at previous projects. Thanks to this experience, we are able to compare the requirements and define which are more and which are less complex. The history of team work indicates how much time we have to dedicate to implement individual stories, and after summing up the points, to implement the entire project. How do we do that? We estimate the degree of complexity of User Stories: From the entire Product Backlog, we choose the least and the most complex story and several intermediate ones and we discuss them with the customer in detail. Those stories are the reference point for the other requirements. The complexity of each story is estimated by the team based on the values of Fibonacci numbers. The sum of points from the stories and the average number of points implemented by the team in the sprint determine the date of project completion. The final stage – the pricing„Big picture” in order to achieve something As whom I want to do something in order to be able to withdraw money when the bank is closed I want to withdraw money from the ATM User Stories should also contain Approval Criteria, i.e. a set of requirements whose completion allows both the team and the customer to be sure that a given user story has been implemented. For the initial pricing, general criteria are enough, for example: entering of the correct PIN code authorises the user; entering of the incorrect PIN code causes display of a message on an unsuccessful attempt; after 3 unsuccessful attempts, the card is blocked by the ATM. Product Backlog is a set of business requirements arranged by priorities On the top, there are features without which the system cannot function, i.e. those that meet the most important business needs. Product Backlog elements most often take the form of User Stories. These are requirements phased as below: Product Backlog What do we need to price a project?
- 4. How do we organise work in a project? The team delivers and presents the functional software after each iteration (the so-called sprint). Presentation of the performed work takes place in a test environment. It is always a functional application, which allows for on- going control of work progress and the possibility to verify the requirements defined at the beginning of the project. Each sprint is a cycle of events taking place sequentially: Planning choosing User Stories for the next sprint from the Product Backlog; setting the goal of the sprint; accepting the scope by the Team and the Product Owner. Daily Scrum Meeting an everyday 15-minute meeting to organise the entire day of work and indicate the blockers; full control, eliminating blockers; self-organisation; Grooming refinement of the requirements; joint development of the Approval Criteria. Review presentation of the features implemented in a functional application; the customer continuously sees the progress; we can make and react to comments on an on-going basis; formal approval of the work performed; Retrospective after each sprint, we indicate how to improve the process and effectiveness of the team; we identify and eliminate our weaknesses; resolutions in a visible place – we control each other; the customer actively participates in the meeting; full transparency of the team.
- 5. Our method requires full control at each stage of the works. To ensure this, the customer has to assign the Product Owner. The Product Owner should be a person with an authority to make decisions so as to be able to answer the questions of the team within the shortest possible time. It is recommended that the Product Owner works in the same location as the Team. This ensures high level of communication, which is the basis of the agile approach to work. On the other hand, when carrying out the works, the team need to have quick answers to their questions guaranteed. What do we need from the customer?
- 6. Quality! v Definition of Done (DoD) is the common criteria of application quality developed by the team and the Product Owner. DoD is defined for each sprint and defines when the requirements are met apart from the Approval Criteria. Definition of Done They indicate the detailed conditions and requirements that have to be met by a feature to be considered implemented. The Approval Criteria are verified at several stages: Only those user stories that are not linked to any errors, Approval Criteria or DOD are considered implemented. Only then we do state the application is functional. Approval Criteria DONE means DONE ! coding tests review
- 7. How we know we will make it on time. Burndown Chart for sprints The progress of works in a sprint is represented on a chart of implemented stories. Each story has a certain amount of points assigned to it; those points indicate its level of complexity. By implementing the story, the team “burns down” the points assigned to it. The chart is updated live and is available to all the persons assigned to the project. Burndown Chart for the project The progress of works in a project can be represented by the chart of “burnt down” points. When the sprint is over, it means that a certain amount of points has been burnt down, based on which we make a simulation of the project progression. Using historical data, we are able to foresee various scenarios for the project and promptly react to any possible deviations from the scenario that ensures success.
- 8. for your attentionThank you vContact: | www.gtFace.com | info@gtFace.com | (+353) 851 261 081