Garansys loves estimates for Agile projects by Alexander Vermeulen
•Als PPTX, PDF herunterladen•
0 gefällt mir•18 views
Alexander Vermeulen from Garansys discusses their use of estimates for software projects. They use function point analysis to estimate project size and backlog items. Estimates allow them to set fixed prices, determine how many backlog items can be completed per sprint based on past velocity, and ensure a consistent level of quality. Garansys relies heavily on estimates to plan projects, set expectations, and deliver software reliably and with a guaranteed output.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (12)
Ähnlich wie Garansys loves estimates for Agile projects by Alexander Vermeulen
Ähnlich wie Garansys loves estimates for Agile projects by Alexander Vermeulen (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Garansys loves estimates for Agile projects by Alexander Vermeulen
- 2. | GARANSYS LOVES ESTIMATES
- 3. | GARANSYS LOVES ESTIMATES
- 4. My story How we use function point analysis How we give project owner control over the backlog How we use estimates for … everything | GARANSYS LOVES ESTIMATES
- 5. We not only love estimates We can not exist without them | GARANSYS LOVES ESTIMATES
- 6. Reliable Scrum | GARANSYS LOVES ESTIMATES
- 7. Guaranteed Software Output | GARANSYS LOVES ESTIMATES
- 8. Indication of Project Size | GARANSYS LOVES ESTIMATES
- 9. Estimation of Project Backlog | GARANSYS LOVES ESTIMATES
- 10. Estimation of next Release | GARANSYS LOVES ESTIMATES
- 11. Sprint Velocity | GARANSYS LOVES ESTIMATES
- 12. Sprint Backlog | GARANSYS LOVES ESTIMATES
- 13. Realization of Sprint | GARANSYS LOVES ESTIMATES
- 14. Quality Delivery | GARANSYS LOVES ESTIMATES
- 15. Summary 1. Early budget check 2. Fixed price per function point 3. Agreed speed in function points per week 4. Product owner determines order of realization 5. Product owner knows what fits in a sprint 6. Agreed quality in number of issues per function point | GARANSYS LOVES ESTIMATES
- 16. | GARANSYS LOVES ESTIMATES
Hinweis der Redaktion
- 1 Garansys loves Estimates Thank you for the introduction Good afternoon everybody. If you have any questions, please raise your hand or get my attention during this talk… And at the end of this talk we will probably have some time for questions as well.
- 2 Garansys For some time, a felt I would like to tell about the way we work at Garansys. When I saw the theme of this afternoon: Estimations & Agile, that was the right opportunity. When we started our company about 12,5 years ago, we wanted to be different…
- 3 Measure > Behave In 2006, project over budget, not delivering the promised functionality or did not do this in time. We wanted to be different on time, within budget and with the right scope. business guru Ely Goldratt. How you measure > people behave What incentive do we give? So, we wanted something else then hours to measure We found Function Point Analysis to be our answer
- 4 My story In this talk I will tell you more about our way of working. How we use function points (indicative and global method) to make quotations and contracts (for development and support). How all backlog items get their function points and how the product owner can use them to plan the sprints. How function point analysis is applied and how we use function points to measure every step of the project.
- 5 Can not exist without estimates We not only love estimates We cannot exist without them
- 6 Reliable Scrum Let me first briefly outline what our way of working looks like. That is the very recognizable Agile way of working. I think everybody recognizes this. How do we apply function point analysis in this way of working? That starts with how we offer software development to our clients.
- 7 Guaranteed Software Output All our contracts have result commitments for projects and support services These commitments are all done using function points Then we make a contract in which we record How many function points will be delivered Using which average speed in FP/week With a maximum number of issues related to the size in FP We call this Guaranteed Software Output
- 8 Indication of Project Size When making the development offer, Start by mapping out the process that needs to be supported Which problem needs to be solved. Make an initial domain model. Using that domain model, we apply the counting guidelines for indicative function point analysis. We know prices per function points for different situations, so we can do a budget check in an early phase of contract negotiation
- 9 Estimation of Project Backlog (1) When we know to process to support and the problem, we create a backlog of only those user stories needed to solve that problem An important point of attention in user stories is the level of detail you map out. If you go too far, it will take a lot of time and we are not really working on "Agile". If you don't go far enough, then you have a too low estimate and the problem won't be solved. We tackle this by describing the functionality in user stories: As [role] I can [do anything] So that [a goal is reached] For getting the right detail: we use the counting guidelines for global function point analysis. For us, each user story corresponds to one functionality to be counted: External Input, External Outputs, External Inquiries, Int. Logical Files or Ext. Interface File. In this way we can easily determine the number of function points within the scope of the first release.
- 10 Estimation of next release In a sequel release, you'll have to deal with it in three types of development work: adding new functionality Modification of existing functionality Removal of existing functionality We use the Nesma counting guidelines for maintenance. Alternative counting guideline indicates that for each change you calculate a factor based on the degree of change in the function: of 25%, 50%, 75% or 100%.
- 11 Sprint Velocity Next step is determination of the average speed of development. The most important is the deadline: When should the problem be solved? We know the average speeds at which team members can work. Usually we use this as a guideline: Analysis & Testing 40 FP/week per person Development 10 FP/week per person Based on these assumptions we can determine how big the development team will be. The minimum speed of a team is 10 FP/week, this can be up to a maximum of 50 FP/week. If more functionality needs to be delivered per week, we will divide the project into parts and set up separate teams. But usually the customer organization is the most limiting factor in determining the average speed. As key users are often busy in their work, but also crucial in working out the user stories and accepting the developed system. Then we determine the duration of each sprint, usually 2 weeks, sometimes 3 weeks. Once that has been determined, we know how many sprints the project will have.
- 12 Sprint Backlog The initial project backlog can change during the project. During refinement sessions the prioritization can change during the project. The most important user stories are listed "at the top". Each sprint gets the top most user stories up to the agreed amount of function points per sprint. Because we have already determined the size in function points for each user story and because the average speed has also been agreed, the product owner always knows very well what can be developed per sprint. We do not have to wait for a planning session where developers will determine the Story Points.
- 13 Realization of Sprint The progress of the sprint is tracked by the number of function points that are “sprint ready”, "develop ready", "test ready" and "accepted". Sometimes it turns out that the content of a sprint contains "difficult" functionality. That is, functionality that is takes more time to develop than usually. We then take care of that by supporting that team with extra people with the need skills. Sometimes that is an extra Architect or a developer. Another time it is an extra tester. For us, progress in a stable speed of delivered functionality is more important than fixed teams.
- 14 Quality of Delivery The sprints works towards the delivery of a potentially shippable product. In order to really get that far, the software must meet all kinds of predefined quality requirements. This is checked at Garansys by various types of tests. The issues found are classified into gradations: high, medium and low. We agree with our clients on a certain quality level which is expressed in the number of not-fixed issues per grade. Our normal standard is 0 high, 2 average and max 4 low per 100 function points.
- 15 Summary Function point analysis and estimates are crucial to our way of working. Without estimates and knowing our metrics, we would not be able to work like this. Our approach offer us these advantages: Early budget check in early stage Fixed price per function point Agreed velocity in function points per week Product owner determines his own order of realization and can change things during the project Agreed quality in number of issues per function point
- 16 Thank you Thank you very much I hope you can use some of these ideas in your company as well. If you have any questions, I think there is some time to talk about them. Otherwise I'll be here all afternoon. During the breaks, you can ask me anything you want to know.