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.
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
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
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.