Function point VS Story Point

1
Function point VS Story Point

• Samir Khanal
• BGSU

These slides are based on contents from sources
listed here
2
Contents

• What is FP?
• How to use FP?
• What is Story Points?
• How to use story points?
• Comparison and use in Agile team.

3
(No Transcript)
4
Father of FPA Allan J. Albrecht

• Function Point Analysis was developed first by
  Allan J. Albrecht in the mid 1970s.
• It was an attempt to overcome difficulties
  associated with lines of code as a measure of
  software size, and to assist in developing a
  mechanism to predict effort associated with
  software development

5
Function points

• Function Point Analysis (FPA) is method to
  measure the functional size of an information
  system.
• The functional size reflects the amount of
  functionality that is relevant to and recognized
  by the user in the business.
• It is independent of the technology used to
  implement the system.

6
Function Point

• Used to estimate a projects cost as a function of
  the target systems attributes rather than its
  predicted size. (Bruce I Blum)
• According to Pressman, Function points are
  derived using an empirical relationship based on
  countable measures of softwares information
  domain and assessment of software complexity

7
Five pillars of Function Points

• Five system properties are typically used to
  compute function point counts
• Number of user inputs
• Number of User outputs
• Number of user inquiries
• Number of files
• Number of external interfaces
• FP is the weighted sum of five counts.
• weighing factors defined for simple, average and
  complex systems.

8
Function Weighing Metric
From Roger S Pressman, Software Engineering a
practitioners Approach, 4th Edition, 85-87
9
Final FP calculation

• FP Count total x 0.65 0.01 x Sum of 14
  factors (min 0 to max 70)
• Example 52 x 0.65 0.01 x 50 59.8

10
14 factors

• Does the system require reliable backup and
  recovery?
• Are data Communications required?
• Are there distributed processing functions?
• Is performance critical
• Will the system run in an existing, heavily
  utilize operational environment?
• Does the system require online data entry?
• Are the master files updated on line?
• Does the online data entry require the input
  transaction to be built over multiple screens or
  operation?

11
14 factors contd..

• Are the input, output, files or inquiries
  complex?
• Is the internal processing complex?
• Is the code designed to be reusable?
• Are conversion and installation included in
  design?
• Is the system designed for multiple installations
  in different organizations?
• Is the application designed to facilitate change
  and ease of use by the users?
• RATE these factors in the scale of 1-5 0- No
  influence, 1- incidental, 2- Moderate3- Average,
  4- Significant, 5- Essential

12
When to count function point?

• In theory, there should be no changes in function
  point count between the end of product design and
  the end of acceptance testing.
• In practice, there is a big difference. It is
  during this time of implementation and testing
  that changes become progressively more expensive
  to make.
• Very often, users and project managers decide on
  change requests, features, costs and schedules
  throughout this time. Function points can be used
  to quantify these negotiations.
• It is not wise to exchange a 100 function point
  enhancement for a 100 function point reduction in
  functionality.
• The work already expended on the 100 function
  points to be dropped must also be considered.

13
What to do with function points? How to use it?

• To measure the productivity of your team or even
  yourself, and then track it over time
• To estimate project effort and schedule
• To measure your productivity and then compare it
  to other organizations and
• To use the data to drive business decisions
  regarding which applications to retain, retire or
  redesign.

14
How to measure the productivity?

• Function points implemented per staff month
  indicates the amount of effort that goes into
  system development.
• A 500 function point application developed by 10
  people in 10 months had a productivity rate of 5
  function points per staff month.
• Function points implemented per calendar month
  indicates the speed with which systems can be
  developed.
• 50 Function point per calendar month
• What kind of staff to count?
• Developers? Support staff? Administrators?

15
Why no FP for Agile Methods.

• The inherent difficulty of this FP Method is that
  it relies on some historic evidence.
• Under IFPUG 4.0, there are rules and guidelines
  that make it possible to count function points
  once the requirements have been finalized.
• In Agile projects, user requirements are evolving
  and not completely finalized in the earlier
  iterations

16
How to Estimate Agile Projects?

• Agile Methodologies believe that Adaptability to
  changing requirements at any point during the
  project life is more realistic better approach
  than attempting to define all requirements at the
  beginning of a project and then expanding efforts
  to control changes to the requirements.
• Agile principle believes in delivering a working
  output and gather further requirements and evolve
  the product
• Some approaches are
• SCRUM
• eXtreme Programming

17
Story points?

• A Story is the unit of functionality in an XP
  project. Progress is demonstrated by delivering
  tested, integrated code that implements a story.
• A story should be
• Understandable to customer and developer
• Testable
• Valuable to customer
• Small enough so that the programmer can build
  half a dozen in an iteration.

18
Example of stories in Travel Planning

• Find Lowest Fare
• Present customer with 10 lowest fares between two
  routes
• Show available Flights
• Show possible flights (direct and with
  connections)
• Sort available flights by convenience
• Sort by time, no of changes, closeness to chosen
  arrival and departure time
• ..
• ..
• Book a hotel
• Show rooms and book an accomodation
• Etc

19
How do we estimate a story?

• Easiest way Base your story estimates in a
  similar story you have already done, if any. The
  story will probably take the same amount of time
  as a comparable story
• Story points indicate the size and complexity of
  a given user story relative to other stories that
  are part of the project
• No standard definition of a story point exists.
• Determining the number of story points in each
  story is subjective. There's nothing you can
  count directly to get the number of story points.

20
How do we estimate a story? Contd..

• Estimating story points is essentially an
  application of the expert opinion estimation
  technique
• A story point is a measure of magnitude. It's
  also a measure of the size of a user story
  relative to other user stories.
• Story points enable effort to be estimated
  without trying to estimate how long it will take

21
How to define a story point

• Ideal day of work (without any disturbance)
• OR
• Ideal week of work
• OR
• As a measure of complexity
• Story points represents NEBULOUS UNITS OF TIME
  (NUTs)

Joshua Kerievsky (http//c2.com/cgi/wiki?Nebulou
sUnitOfTime)
22
Estimation of story points.

• Estimate as a team team is the owner of story
• As who will work on story is not finalized so no
  question of ownership
• Since a team derives story, more useful than
  individual estimate.
• More the developers involved better the
  estimates.

• Using points forces everyone to think relatively
  .

23
Process of finding story pointsWideband Delphi
Approach

• Identify stories (Example)
• After stories are identified
• Each developer estimates the points (depending on
  factor to use ideal day of work, or complexity)
  which is not yet known to other developers.
• Then share the estimate with other developers.
• If estimates differ, ones with differing views
  present their ideas.
• Customer clarifies any issues as they come up.
• Again write the estimates until the differences
  settle and everyone comes to an agreement.
• The Goal converge on a single estimate that can
  be used for the story

24
Triangulation

• I'm giving this story 2 points because it feels
  like it's twice as big as that 1-point story and
  about half as big as that 4-point story.
• Magnitude should be comparable.
• Posting the story cards on white boards can be
  helpful for comparison.

Story 2
Story 1
Story 3
http//www.think-box.co.uk/blog/2006/02/ideal-ti
me-vs-story-points.html
25
Using Story points Project Velocity

• Project estimation is a matter of considering how
  many story points a team can implement and verify
  in a single iteration. (due to time boxing of 2-4
  weeks)
• This productivity measure of story points per
  iteration is termed project velocity.
• The team does not commit to implement more story
  points in a given iteration than their previous
  experience indicates is feasible, based on their
  project velocity measures.
• Because the user stories are defined at a fairly
  high level, more uncertainty is associated with
  their implementation estimates than for more
  fully specified requirements.

26
The Cons of story point!

• Developers might correlate Story points with
  time.
• A 1-point user story may take 4 ideal hours to
  complete, but it's also possible that another
  1-point user story will take less, or indeed more
  than 4 ideal hours.
• developers start to estimate in ideal time first
  and then convert to story points.
• the very purpose of using story points is lost.
• Story points are unnatural for the customer, who
  are more used to getting estimates in time
• making estimating units more abstract make
  estimating and planning more confusing and
  difficult.

27
References

• Cohn Mike, User Stories Applied for agile
  software development, Addison-Wesley
• Blum Software development a holistic View,
  Oxford Press.466-467
• Beck Kent, Fowler Martin, Planning Extreme
  Programming ,
• Wiegers Karl W., More about Software
  Requirements Thorny Issues and Practical Advice
• Pressman Roger S, Software Engineering a
  practitioners Approach, 4th Edition
• http//www.think-box.co.uk/blog/2006/02/ideal-time
  -vs-story-points.html
• http//c2.com/cgi/wiki?NebulousUnitOfTime