8
Kliknij, aby edytować styl wzorca podtytułu v Contact: | www.gtFace.com | [email protected] | (+353) 851 261 081 Agile Process

gtFace: Agile Scrum

Embed Size (px)

Citation preview

Page 1: gtFace: Agile Scrum

Kliknij, aby edytować styl wzorca podtytułu

vContact: | www.gtFace.com | [email protected] | (+353) 851 261 081

Agile Process

Page 2: gtFace: Agile Scrum

Because we are interested only in the success of the customer. SCRUM ensurescontrol at each stage of the works, full transparency of the project and closecooperation with the customer. We know that the requirements defined incontracts often prove inadequate or unnecessary: we are not afraid of changingthem. We are interested in a product that meets the customer’s requirements,which is not always the same as “compliant with the documentation”. Agileapproach is the success of our customer. The success of our customer is also oursuccess.

Why we choose SCRUM.

Page 3: gtFace: Agile Scrum

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:

As the owner of a bank account

The project pricing is carried out by determining the level ofcomplexity of individual requirements. Our evaluation ofparticular stories is based on the knowledge and experiencegained at previous projects. Thanks to this experience, we areable to compare the requirements and define which are moreand which are less complex. The history of team work indicateshow much time we have to dedicate to implement individualstories, and after summing up the points, to implement theentire project. How do we do that? We estimate the degree ofcomplexity of User Stories:

From the entire Product Backlog, we choose the least and themost complex story and several intermediate ones and wediscuss them with the customer in detail. Those stories arethe 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 ofpoints implemented by the team in the sprint determine thedate 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 whenthe bank is closed

I want to withdraw money from the ATM

User Stories should also contain Approval Criteria, i.e. aset of requirements whose completion allows both theteam and the customer to be sure that a given user storyhas been implemented. For the initial pricing, generalcriteria 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 requirementsarranged by priorities On the top, there are featureswithout which the system cannot function, i.e. those thatmeet the most important business needs.

Product Backlog elements most often take the form ofUser Stories. These are requirements phased as below:

Product Backlog

What do we need to price a project?

Page 4: gtFace: Agile Scrum

How do we organise work in a project?

The team delivers and presents the functionalsoftware after each iteration (the so-calledsprint). Presentation of the performed worktakes place in a test environment. It is always afunctional application, which allows for on-going control of work progress and thepossibility to verify the requirements defined atthe beginning of the project.

Each sprint is a cycle of events taking placesequentially:

Planning

choosing User Stories for the next sprintfrom the Product Backlog;

setting the goal of the sprint;

accepting the scope by the Team and theProduct Owner.

Daily Scrum Meeting

an everyday 15-minute meeting toorganise the entire day of work andindicate the blockers;

full control, eliminating blockers;

self-organisation;

Grooming

refinement of the requirements;

joint development of the ApprovalCriteria.

Review

presentation of the features implemented in a functionalapplication;

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 andeffectiveness 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; fulltransparency of the team.

Page 5: gtFace: Agile Scrum

Our method requires full control at each stage of the works. To ensure this, thecustomer has to assign the Product Owner.

The Product Owner should be a person with an authority to make decisions so asto 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 theTeam. This ensures high level of communication, which is the basis of the agileapproach to work. On the other hand, when carrying out the works, the teamneed to have quick answers to their questions guaranteed.

What do we need from the customer?

Page 6: gtFace: Agile Scrum

Quality!

vDefinition of Done (DoD) is the common criteria ofapplication quality developed by the team and theProduct Owner. DoD is defined for each sprint anddefines when the requirements are met apart from theApproval Criteria.

Definition of DoneThey indicate the detailed conditions and requirements thathave 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. Onlythen we do state the application is functional.

Approval Criteria DONE means DONE !

coding tests review

Page 7: gtFace: Agile Scrum

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 storyhas 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 isupdated 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. Whenthe sprint is over, it means that a certain amount of points has been burnt down, based on whichwe make a simulation of the project progression. Using historical data, we are able to foreseevarious scenarios for the project and promptly react to any possible deviations from the scenariothat ensures success.

Page 8: gtFace: Agile Scrum

for your attentionThank you

vContact: | www.gtFace.com | [email protected] | (+353) 851 261 081