In a software development life cycle, there are set of activities involved including the requirements collections, transforming requirements to design and then coding and testing. In all these activities, people have to estimate for all these activities and project to the management that the total time taken to execute the project. In these process of estimating the software activities/tasks, there can be unknowns which are never estimated and there by impacting the project cost and schedule. Are there any ways to anticipate all the project unknowns? Unknowns can be implicit requirements, requirement misses, may be did not consider the impact of other sub-systems that work with the software in hand. In this article, I want to share the real time examples, challenges faced during software estimations and some of the best practices to minimize the chance of not anticipating unknowns.
Unknowns are everywhere, no matter what software development methodologies are being followed. May be, following a particular development methodology may reduce the risk of identifying unknowns late during the cycle of software development, however there are definitely the unknowns. This is true in our real-life also. In a day, you will have some unexpected things happening and anticipating them is a clever and smart idea. The same applies during software development process too.
1. Have expertise in the area of work/domain: The experience and expertise plays a very important role here. If the software development team is not experienced enough, then the goal can be set towards achieving it. It’s all about thinking "big". We'll hear people saying that "this particular scenario was never thought about by any one". So, the question should be "Why is this happening?, Why nobody thought about this scenario"?, This can be solved by following rapid problem solving method and come up with action items and more importantly sustaining them all the time. This is how team can learn and adopt.
2. Do not just go by the past data: Most organizations maintain project/program metrics and this data is taken as input for the current project estimation. However, this may not lead to the accuracy since 'time' plays an important role. The metric data is somewhere in the past and may not apply in the current situations simply because many things might have changed including 'Customer mind'! Deficiently the data can be looked to get initial hint but should not be taken granted. Other parameters such as deployment scenarios, customers' way of perceiving the software etc would have changed.
3. Go Agile: As I mentioned in the beginning of this post, the software methodology also has some good news. The true fact is that no one can anticipate every unknown 100%. So always we can go by the rule, "Whatever is done is complete" and continuously try making it complete by showing/demoing to intended customers incrementally and this is what exactly agile methodology does. The Agile or Scrum helps discovering the missed out, implicit requirements early.
4. Discuss in group: The software estimation should not be a single person's effort. This may go wrong. Instead it should be collective opinion of all the team members involved in the development. You might know the saying "If all think alike, then nobody is thinking...”. So have team members/give chance for everybody to think in different aspects to project the scenarios. This is more like a "Brain storming" activity. This definitely helps.
5. Have customer requirements at Granular level: Customer requirements are always unclear at the first look and noisy. The more detailed and granular are the requirements, the more accurate estimate is possible. It makes sense to spend sufficient time detailing out the requirements. This activity helps all the developers understand the requirements nearly 100% and helps digging deep to find out the unknowns.
6. Avoid assumptions while finding out use cases: Assumptions are the major hurdles to handle. One cannot go with project execution with lot of assumptions. Basically assumptions are unknowns. Since we are on the goal of finding unknowns, remove all assumptions and get the clarity before proceeding further in the project execution.
To find out unknowns, there are no defined processes, the techniques explained above are just some thoughts that may help find the unknowns. In software development, the tackling unknowns are always a challenge. But finding unknowns as much as possible early in the software development life cycle leads to very less or no unknowns in the later cycle. In one of our examples, two people sitting together and writing down as much user scenarios as they can think of and reserving enough time for all team members to discuss helped. So, it depends on the nature of the software being developed, the team experience level, software methodology in use, past experience, etc. So, we can only learn from past and come with certain best practices and guidelines to deal with project unknowns.
If anyone has any best practice that helps find unknowns, please share...
Also see
Estimation of User Stories in Scrum Methodology
