Search the Community

Coming soon.

Estimations for software development seem to be the bane of almost every company, but why is that really? Why is it so difficult to approximate the time and effort required when we do this all the time? There are a few reasons and in this article I will go over how I do my estimations and give you some of my experience on how you can maintain a 90% accuracy in any project. For a good estimate you need to start with one very important thing: define if you estimate based on time to complete or time to deliver. These are very different because the time to deliver will be substantially higher and much more prone to variations. This is because in the daily work you will be dragged into meetings, have people distracting you and so on. For good estimations we always estimate on time to complete as our basis. Stop doing happy estimates The worst thing you can do is making happy estimates. These are estimates based on the utopia that everything will work smoothly and you will be left in total isolation to focus. It never happens and Murphy is always present. Happy estimates may seem good because the product owner love low estimates, but they hate when you fail to deliver. Happy estimates usually happen when an architect is stressed and throw out a guesstimate on the fly. It will almost always bite you in the butt because not only will everything seem easy to the architect, so they will underestimate it, they also never consider Murphy. You do not estimate to be nice, you estimate to give a realistic view on when something can be available in production. If you have a hard time to stop making happy estimates, then implement this very simple rule: "Any time that is needed beyond the time you have estimated you will do in your own time without payment" Take your time doing estimates An estimate is not a guesstimate that you throw out on a high level requirement. An estimate is your promise on when you can deliver and as such you should take your time and think that through. Don't sit around doing arbitrary guess work in a planning poker or play with t-shirt sizes unless you want to avoid doing any estimates at all. That type of guesstimating is for high level requirements, so make sure they stay there. Break down the requirement and use your experience to guide you to a first number in your estimation. This estimate is how long it will actually take to sit down and build based on the requirement. Make sure that you ask questions to clarify where needed so have the information you need. This is also a good time to start working on a solution design to make sure you have considered things that may not always be apparent. For example validation of data in integrations or extending a JavaScript validation for a new form. When we have done this, the number is still wrong, but we need it as a starting point. Add the things you forgot Now that you have done your estimate, many think they are done. That is rarely the case, so let us add the things that is not included yet. The most obvious problem that I see a lot is that the estimates is usually done by the most experience person, which also usually is the one that work fastest of everyone in the team. So what we do is to look at the estimate and the team, then we adjust based on what the slowest person in the team think is appropriate. This way we know that the base estimate is reasonable for everyone on the team. The second thing we do is to consider Murphy. Things always happen and based on the complexity we increase the estimate with 20-100%. Not having room for mistakes is in itself a very big mistake. It will almost always happen and if it does not happen for this particular task we will either be able to resolve things faster than expected, or we have more time for other tasks. Either way that is a positive thing. The third thing to look at are testing. All code should have unit tests and it is often forgotten in the estimate. You also have non-functional requirements such as loading times and browser support that you must consider. As a developer you are also responsible for testing the code and this should be added as a second estimate. For many estimates this alone will add 20-200% or even more to the estimate. This is especially true for frontend development where you often have 18+ variations just for devices and browsers. These three very simple things easily multiply the original estimate two to three times. Now let us consider your efficiency! A factor that is very often overlooked is efficiency. No person in any team will ever have 100% efficiency in the sprint. I do not mean your focus level during the day, even if that also is a factor, I am talking about those pesky things that break your concentration. Things like meetings, stand-ups, code reviews and all those "I just want to ask a quick question", cost a lot of your time during the day. In my experience most teams will have an efficiency of around 40-60% depending on how often they are disturbed. Depending on if your product owner understand estimation or not you can choose if you add the efficiency in the estimate, or if you have that as an external factor in the sprint itself. If you are new to this part of the estimation I suggest that you start with 50% efficiency and then adjust over time as you get better at estimating your efficiency. With this step we now add a second two time multiplier and you are now close to a realistic estimate. This may seem like a lot This may sound like the estimates always will be very high compared to how you are working today, and you are right. This is why you always feel stressed and why you fail to deliver on promise in every sprint. It is why we invent things like story points to mitigate our inability to take responsibility for things we can't estimate properly. Realistic estimates are just that and if your estimates are far lower than what you get doing estimates this way, then remember this very simple rule: It is always better to overestimate and over deliver than to underestimate and under deliver. The Quick Summary Make estimations in actual time to complete, not arbitrary measurements. Take your time to understand the task at hand and stop guesstimating. Adjust the estimate to fit the slowest person on your team. Add task for testing and make estimation separate for that. Remember that things always go wrong, so make room for that. Make sure that your efficiency is considered and calculated into the time to deliver. Making good estimates is based on experience and knowledge. This means that like other skills you can get better at it. If you constantly work with arbitrary measurements like story points and you constantly fail with no change to your estimation process, then you should stop doing that. Not only will you fail at a crucial part of your work, your inability to provide accurate estimates actually cause harm in the form of stress and frustration. It is up to you if you want to spend your time in constant failure or constantly provide estimates that are realistic and dependable. Learning to make good estimates is not rocket science, just common sense and experience. So start doing it today.

As a requirement analyst I see many try to make estimations as if that is your prime objective. It is not. Your job is not to provide estimates, but to make sure that the need is defined enough to be properly estimated. You are the conduit that translate business need to the persons that are responsible to realize that need. That is your only responsibility. So when you break down need to user stories or use cases your focus should always be to ensure that the persons that will realize the need have the information they need to make the final estimations.

coming soon.

coming soon

coming soon

coming soon

coming soon

coming soon

Coming soon

Coming soon.

Security, penetration...

Coming soon.

Coming soon

Coming soon

Coming soon

Coming soon

Coming soon

Coming soon.

Coming Soon.

Coming soon.

coming soon.

When it comes to Confluence the most important thing to keep in mind is how to structure information. Confluence as a tool has endless of possibilities, which is both its strength and its weakness. You can easily build monsters if you do not have a documentation strategy. One of the areas I have found that it is pretty easy to define a structure is for system documentation, so we will start with that here. One key aspect of good documentation is to limit the number of entry points in our documentation tree. I like to use the 7+1 design for system documentation. That is because it is easy to remember, and it is for the most part a logical division of the documentation for a system. We then try to maintain the number of categories under each node as well to avoid the categorization to be too broad. The Node sections we want for system documentation are: Architecture Document Instruction Quality Requirements Technical Solutions Initiative Visual Design The plus one in this list is the Visual Design part since not all systems have a graphical interface.

Test should be included in the Inception phase.

Accept Development Release Planning Accept Change Release execution