This document provides guidance for creating initial effort estimates for software development projects during the pre-sales stage when requirements are uncertain. It recommends modeling the domain using use cases and user stories to organize requirements in a granular way. Complexity levels and estimated time ranges are then assigned to stories. This allows calculating an initial effort estimate by summing the estimates for all stories while accounting for risks. The process is illustrated with an example modeling an app for social sharing and estimating its development at around 3 months for a team of 3 engineers.

1. Quick and easy initial effort ETA for
software development projects
Alex Moskvin
CEO/CTO Plexteq

2. About myself
• CEO/CTO Plexteq OÜ
• Ph.D in information technology area
• Interests
• Software architecture
• High loaded systems
• AI/ML + BigData
• Knowledge sharing ;)
• Building local and offshore development teams
• Follow me
• https://twitter.com/amoskvin
• https://www.facebook.com/moskvin.aleksey

3. Disclaimer ;)
This talk is based on personal experience.
Use at your own risk.

4. So what?
Okay, you’ve gotten a request for POC estimation
on a pre-sales stage. What’s next?

5. Relevance
Pre-sales, POC …
• Uncertainty and no visibility
• Fast paced environment
• You need to react quickly

6. Relevance

7. Relevance

8. Relevance
Pre-sales, POC …
• There is no bullet proof approach for making effort/cost estimates

9. Relevance
Pre-sales, POC …
• There is no bullet proof/standard approach for making effort/cost
estimates
N * rand(100)

10. Relevance
Pre-sales, POC …
• There is no bullet proof/standard approach for making effort/cost
estimates
N * rand(100) + 30%

11. Relevance
Pre-sales, POC …
• Usually fixed price
• All is agile

12. Relevance
Pre-sales, POC …
• Uncertainty and no visibility
• Fast paced environment
• Usually fixed price
• No bullet proof approach for making effort/cost estimates

13. So what?

14. Let’s organize chaos
What do we have on pre-sales POC planning phase:
1. Customer representative
2. Engineering team
3. High level requirements (list of features)
4. We know technical stack
5. Budget estimate

15. Let’s organize chaos
What usually happens:
• Non agile, engineering driven approach wins
Why it’s suboptimal?
• Focuses on low level technical details which are non-granular
• Doesn’t give easy way re-estimate with changed features layout (user
stories)

16. Let’s organize chaos
What is our experience:
• Think in feature/story based way
• Always build business domain model
• Use UML for modeling - especially use cases and process flows

18. Screw it, let’s do it!
Legend:
• iOS application that helps with posting text, photos and videos for
lazy and over social people (Twitter, Facebook, Instagram, Snapchat,
…)
• Should have server side for storing authentication data and linked
accounts
• There should be a back office system for accessing user data and
overviewing system operation

19. Screw it, let’s do it!
Start with modeling roles/actors

20. Screw it, let’s do it!
Focus on use cases for each
of the role/actor

21. Screw it, let’s do it!
Drill down to stories

22. Screw it, let’s do it!

23. Screw it, let’s do it!
1. Define implementation points (backend (B), frontend (F),
documentation (D))
2. Mark use cases with implementation points

24. Screw it, let’s do it!

25. Screw it, let’s do it!
1. Define complexity levels
1. L (green) – low complexity
2. M (yellow) – medium complexity
3. H (red) – high complexity
2. Define execution time for every complexity level
1. L – 1 week
2. M – 2 weeks
3. H – 3 weeks
3. Mark use cases with complexity levels

26. Screw it, let’s do it!

27. Screw it, let’s do it!
Add risk buffers to individual tasks if you feel those are connected with
risks.

28. Screw it, let’s do it!

29. Screw it, let’s do it!
Calculate:
• H – 3
• M – 4
• L – 16
S = (3*3 + 3*0.3 + 3*0.3) + (4 * 2) + (16 * 1) =~ 35 w
(~ 3 months for team of 3 engineers)

30. Screw it, let’s do it!

31. Questions?

32. We are hiring!