Depending on the type of project and industry, non-functional requirements may carry a different weigh. Implementing them may be more or less complicated as well. The project estimations and restrictions regarding budget and time frame often make it challenging for teams to achieve the set commitments and deliver the work on time.
Consider the essential functional priorities of your project to make sure developers focus on them first. In the worst-case scenario, you can postpone the least critical tasks to another project phase.
You can choose between several approaches for estimating your project, depending on its type, complexity, number of requirements, and delivery times. Here are the most common estimation strategies for software development projects:. Record all the project assumptions that may influence the estimation and the planning of the project.
That way, the person in charge of evaluating the estimation will have all the information required to assess it. This is the best strategy for avoiding the risks of misunderstanding by ambiguous or lacking information. Development teams take advantage of estimation tools that help to automate the process and make agile estimation more accurate. Another benefit of agile estimation tools is that they help to make the group tasks easier and provide teams with rich reports about their estimation efforts.
Traditional software teams estimate projects using a time format: days, weeks, months. But agile teams often use story points which rate the relative effort of work in a Fibonacci-like format: 0, 0.
That might look complex, but the level of abstraction involved in story points actually helps teams to make tough decisions about the difficulty of their work. Also, story points allow counting in the non-project related work emails, meetings, and interviews.
Once the team agrees on the relative effort of each story point, assigning points is a quick and effortless process. Note that completed story points reward team members for solving problems based on their difficulty, not the time spent on the task. That helps the team to focus on delivering value, not just spending time on the project.
Agile development teams that use story points often participate in an exercise called the planning poker. During the planning poker, the team takes an item from the backlog, discusses it briefly, and then each member is asked to formulate an estimate.
Then everyone holds up a card with their estimate. This exercise helps to understand the reasons behind different estimates and come up with a more accurate final estimation. If a development team has worked with a specific technology in the past, the developers will be more aware of the potential complications and issues that may crop up during the process.
This knowledge plays a crucial role in agile estimation. Code with technical debt. Technical debt is a serious issue, and every project manager and development team needs to recognize why and when it is incurred. If you suspect technical debt has been incurred in the past, remember it alway means extra cost and effort to pay down or deal with in the future.
Untried methods. Any time you are trying something new which you haven't done before, consider the potential for required research, trial and error, and troubleshooting. External dependencies. If you are highly dependent on a third-party product, service, or vendor, consider the impact of a disruption, unexpected problem, or discovery that something is not supported.
It may be cause for doing extra due diligence or planning for contingencies. Volatile requirements. If the requirements are subject to change quickly due to market unpredictability or an influx of new information. If it must be addressed now instead of later, time for retooling or refinement may be required.
You will need to analyze the specifics of your own project tasks to determine additional risks. The estimate for a task should reflect its inherent risk and uncertainty. This can be difficult because we don't know, ahead of time, whether a particular task will go smoothly or not; how do we predict a specific outcome? This is where buffering makes sense. In math and science, an analogous concept is the "confidence interval".
It makes sense to add a reasonable confidence interval to this baseline if we want to ensure a high probability of falling within the estimate. This method has you come up with two estimates for every task: what you consider to be a "baseline" estimate i. Note how this is superior to simply "padding" an estimate; it calculates the buffer for each task based on the amount of uncertainty inherent to that task.
This is a more empirical and less arbitrary approach to buffering. I've often seen project managers who supplied an estimate as a total number, or as hours by role, asked to explain themselves to shocked or skeptical stakeholders who don't understand why the estimate is so high. The best way to handle this drama is to avoid it, which you can easily do if you are transparent with how the estimate was arrived at.
The way to do that is to show an outline of how it all breaks down, particularly any "hidden tasks" that people may take for granted. I generally build a template to do just that in either MS Excel or Project. Below are a few examples using MS Project. These are fictional projects with fictional tasks, and simplified for the sake of brevity. However, they illustrate the basic idea.
Here is a breakdown of activities by phases of the "SDLC":. In this next example, I break down the back-and-forth "revision and review" process inherent to the typical requirements or design effort. This captures some of the "cost of collaboration" and is important when the number of "rounds" it takes matters:. Finally, whenever incremental variables affect the estimate, I always prefer to itemize them out rather than batch them together.
That's because they represent "variable costs" and and I don't want them to be misinterpreted as "fixed costs". If your estimate is contingent on how many website pages you're building, for example, or how many customers you're supporting, or anything that could be added to at the last minute, whether intentionally or not, you need a rationale for why it affects the estimate. Listing things out makes it clearer what the estimate does and does not include:.
The actual estimates for each line could be in hours, days, or even weeks, that is for you to decide. The point is that the more you can do to do make your estimate easy to understand at a glance, the more efficiently you can get through the presentation and acceptance process.
This is a real fear for organizations trying to hit aggressive targets. It contributes to planning fallacy, because it makes us worry about overestimating , and the potential waste that will occur if we do. The fact is, most of the time we think we're overestimating, we're actually underestimating; but in the case that we do, we should turn it into a benefit instead of a liability.
We can do that by setting "stretch goals" for the estimate that are not promised, but will be delivered as "extras" if time permits. In other words, any overestimation should be used to deliver more than what was expected. This could be in the form of extra features, extra "polish" to features, or even just launching early. If the estimate turns out to be adequate only for the original scope then no harm is done; but if you do manage to perform under the estimate, then consistently providing additional value is the way to prove to everyone that they need not worry about Parkinson's Law.
If there's one truism about estimates, it's that someone always wants them to be lower, and you may feel pressured to do that. Your analysis will be for nought, however, if you modify your estimate under duress because someone had a poor reaction to it.
To avoid this fate, it is best to be prepared for it in advance. This means having a plan for when your estimate gets a "no", as well as understanding how to say "no" to unwise concessions. To effectively navigate such conversations, you must not take anything personally. Take it as a rational debate on specific concerns, and nothing more.
Do not fall into the trap of thinking that arguing your side means acting or coming across as belligerent, unpleasant, or self-centered. It's quite the opposite. By defending your estimate you are actually proving that you care about all parties.
If you are truly interested in the project being a success, than defending a good estimate is a sacred trust. Basically you want to do four things:. First, you need to convince others that you really are trying to estimate objectively, with the success of the project in mind, and that your method makes sense. Don't feel bad if others imply that you must prove this; it's all part of the game when time and money are at stake.
This is where all the analysis you've done becomes useful a second time; just walk everyone through it. When you show everyone exactly how your estimate breaks down, and explain the rationale behind each part, it will put people at ease.
Just seeing the details and hearing a strong explanation is convincing enough for most. If there is disagreement in an area, you should discuss it point by point instead of arguing over the estimate as a whole. A big part of getting on the same page is about agreeing on a quality standard and the level of effort necessary to reach it. What often happens is that stakeholders either haven't considered or don't understand the amount of extra time and work involved to reach the quality level they desire.
This can lead to vastly different perceptions of how long something should take. First, be ready to stand for whatever minimum level of quality you feel is the responsible choice for the project. Second, learn to explain, in clear terms, what is involved to reach that level of quality so that others understand.
Third, if cuts have to be made that you know will impact quality, ensure those are communicated, understood, and accepted as a tradeoff. Getting an estimate that was bigger than expected is par for the course. Don't let it stop things from moving forward. The stakeholders want to feel like they are in control of the project, and you take that feeling away if you take an "all or nothing" stance with the estimate.
Instead, acknowledge the stakeholder's concerns or constraints, and provide options. Offer them tradeoffs based on scope, assumptions, or deadlines. If things start sounding unreasonable, clarify and review in detail the quality expectations; sometimes that is needed for them to realize it. What happens if you concede to an estimate that you know in your gut is risky?
Remember that planning fallacy occurs even when people think they've made a good estimate. If you know you made a risky estimate, odds are you have really set yourself up for trouble. Let's take an inventory all of the possible consequences; missed deadlines, money problems, broken relationships, burnt out developers, poor quality, unsuccessful product launch, loss of business, loss of reputation, low morale--did I leave anything out?
None of that is good for either you or your client or stakeholder. Therefore your attitude towards estimating should always be about making the project successful. Once people see that you have their interests in mind, you can move away from a negotiation mindset to a mindset of collaborative problem-solving--which is where you wanted to be all along. I think we can agree these four steps are straightforward.
However, since negotiation skills are usually not taught in companies, it will be incumbent on you to develop your own skills in this area. Imagine you are driving a car cross-country to someplace you've never been, and your speedometer is broken. All you know is that you have to cover miles to reach your destination, and the only gauge that works reliably on your car is your trip meter.
How can you estimate how long it will take you? Simple math can help. Check your watch, drive for miles according to your trip meter, then check your watch again.
You now know about how long it takes to drive miles. Since you have miles left, multiple this time by 9 and you have a decent estimate for the remainder of the trip. To get more accurate as you go along, take the running average after miles and apply it to the next , and repeat the pattern every miles. Notice how much easier this is than if we tried to predict our average speed.
We cannot reasonably expect to maintain the same speed throughout the trip. Instead we have to consider many variables such as:. The percentage of freeways vs.
The occurrence of school zones, construction zones, and accidents. If we need to give the time of our arrival based on a predicted speed, it's going to be difficult to guess correctly.
On the other hand, if we take an empirical approach, as we do by measuring our progress and deriving our speed, we can forecast a more likely arrival window. This is the essence of the Agile approach. It seeks to bypass planning fallacy by focusing on observable results. The key is to measure and quantify how much work you can get done in a set amount of time. Once you have that figure, you can build a projection of how long the full project will take.
Here are the high level basics for doing that:. Popularly called a"sprint", we need a consistent length of time to use as our "divisor" for measuring our productivity. Usually set between 30 days to 2 weeks, the question is not "how much work do we think we can get done" in a sprint, but "how much work did we get done?
This measurement gives us our "working speed", or sprint velocity , which we can use to calculate our "completion window" for the full project.
Note that in order to measure this accurately we need to carefully define what "done" means. If we base our measurement on work that's only partially, but not completely done, than we overestimate our true velocity and its real value becomes hard to determine.
The recommendation is that the work from a sprint should be so complete that it results in working code that is "ready to deploy". We need to do more than simply track the "hours" spent working on requirements. We need to determine how much requirements we can get to "done" within the timeframe of our sprint. The key to doing that is to break the requirements into measurable units and to determine how many of those units we can complete each sprint.
The first step is to make the requirements granular; this can be done by breaking them into user stories as described in A Short Guide to Writing Software Requirements. This way we can measure how many user stories we are getting done each sprint.
However, user stories are not all the same level of effort; some are bigger or smaller than others. To compensate for this fact, we need to estimate, not how long it will take to complete each story, but rather, the relative size of each story by comparing them to each other. To be useful for measurement purposes, we need to do it quantitatively. One technique is to assign each story a rank or score in terms of points, called "story points".
The story points should represent relative scale. In other words, if a particular user story has a score of "1", then a story that is twice as big should get a "2", and a story four times as big should get a "4". Different combinations of stories that add up to the same number of points should represent similar levels of total effort.
Using a consistent set of story point assignments helps standardize the estimating process. The most popular method is to use the "Fibonacci" sequence, which is to use the following set of numbers: 1, 2, 3, 5, 8, 13, Other number sets are possible to use, but it helps if the gap between points is enough to clearly differentiate levels of effort, yet not so big that story sizes can be vastly different.
Any story greater than 21 points should be subdivided into smaller stories if possible. When assigning story point values, one should consider the same costs, risks, and uncertainties we looked at in predictive estimating. If a story has a fair amount of uncertainty, for example, or will require a lot of testing, or has a complicated deployment, those are all reasons to bump up its story points.
This is why estimating story points is not just the domain of the developers, but the responsibility of an entire cross-functional team, which can assess all the considerations for sizing a story, beyond just "coding". Story points are essentially an "abstraction layer" between how we big we think a story is and how long it actually takes. For example, let's say that we think a story will take man-hours.
Given the odds of planning fallacy, let's say it actually took us hours to complete, when all is said and done. If you keep estimating each story directly in hours, you are likely to make this error every time. On the other hand, let's say we gave this story 5 story points. We thought 5 story points equaled hours, but it looks like 5 story points really equals hours. In fact, however, we don't even need to keep track of how many hours it took.
We just need to keep track of how many story points we actually completed within a sprint. However many story points that was, it was logically equivalent to however many man-hours we had to spend. Thus, even though a story point is an approximation, it's useful IF we use it as a mechanism to mitigate planning fallacy. It is then a matter of being consistent with our story point estimates, and measuring how many story points we can complete in a sprint, by adding up the points for all the stories completed within a sprint.
This is our "sprint velocity", which we can use as a reasonably empirical measurement of how much we can accomplish in future sprints. There are a few things to keep in mind when calculating sprint velocity. First, only completed stories should count towards sprint velocity; giving "partial credit" for "partially completed" stories should be avoided; we are trying to measure how long it takes to "get to done" which means only counting that which made it across the finish line.
Additionally, we should avoid consistently having incomplete stories "roll over" from one sprint to the next. That indicates planning fallacy, because it means we are overcommitting to the amount of work we think we can complete each sprint. Rather, our goal is to always complete whatever work we committed to for the sprint if any time is left over, we should deliver "extra", just as with the predictive method ; this is the definition of an accurate estimate.
Therefore, once we have determined our sprint velocity, we should use it as a guide for what we commit to each sprint.
Note that I used the word "commit" because the amount of stories taken on for a sprint should be a team decision, rather than simply assigned from "on high". If work is simply assigned, it negates the empirical method, and usually results in overcommitment. Sprint velocity represents observable evidence as to how much should be taken on in the next sprint, unless the team believes there are special circumstances why they may be able to accommodate more or less work.
In other words, future estimates should be calibrated against past results. This is the point of measuring and using sprint velocity. With that being said, realize that it will take some time to "settle" in on your average sprint velocity. By proposing to the client to adjust the requirement, it may open up the possibility for a better solution that even ends up being faster to build.
If your solution ends up saving time and money , the client will definitely appreciate it. Should I just print both and hide one with CSS? What you should do: ask the client if the reason for this is just the size of the image, or are they planning on uploading different visuals.
It may turn out that this was exactly what the client wanted. Development teams usually agree on a particular sequence for their estimates, e. In agile software development, estimates are typically done with story points rather than actual hours. The two story point sequences most frequently used are 1, 2, 4, 8, 16 and 1, 2, 5, 10, You and your team should set the highest limit for a single task.
As we just saw, no task should take longer than 16 hours, or 20 in a Fibonacci-like sequence, for example. One thing we do that I believe has really contributed to this is the fact that several different developers often go through the estimates for the same task, which gives us an even better understanding of the task and its potential pain points, as well as helps us be even more accurate in the future.
I hope these tips will help you in all your development estimates. All of this may take a bit of time getting used to for those who are just getting started with client projects, but the more projects you do, the more intuitive it will all become, and soon you will start feeling much more confident in making accurate estimates. Making accurate estimates in software development. Written by:. Development Business. This is the information you have about the trip: There will be 6 - 10 people.
The trip will last 3 - 5 days. People have different food preferences - you need to be innovative and think outside the box.
0コメント