Zülfikar Karakaya

I want this much. When can I get it? We create a fixed-scope plan in response to the question of “when will all of this be done?” There are 3 steps here Sum the product backlog items Estimate velocity as a range Use the sum of the backlog divided by the velocity range to determine a date range What we know The project size is 120 points Velocity is in the interval 15-20 So you can calculate the duration as 6-8 sprint. And you have to decide a balanced duration to get the contract and to deliver everything in time. With agile, it is absolutely possible to commit to a fixed scope. A fixed-scope plan answers the question of when a set of product backlog items can be delivered. Ideally a fixed-scope plan will be given as a range: “You will get that fixed scope sometime between this and that date.” Unfortunately, plans often have to be narrowed and overly specified into single-date estimates because bosses, clients, and customers prefer the false cert...

We need it on this date. How much can we have by then? There are there steps here : 1. Determine how many iterations you have 2. Estimate velocity as a range 3. Use that "range x the number of iterations" to partition the backlog into Will Have, Might Have, and Won't Have . In general you want to balance for two types of risk. Always determine the range even if you need to communicate a single value. So you can show the truth about the project by sharing the math above. Then find an appropriate balance between delivery and expectation risk. And you can communicate that as your point estimate. You definitely don’t want to always promise a boss, client, or customer that you will deliver at either of these extremes. In most cases you will want to promise to deliver some amount of the might-have region of the product backlog. Exactly how much to promise should be determined by finding an appropriate balance between failing to meet initi...

There are two approaches to estimate tasks Gut-feel Estimate by analogy - A similarity between things on which you can base a comparison Triangulate - compare it at least two other stories When you estimate, it is OK to trust your gut or intuition. It should rarely be your primary basis for an estimate, but an estimate feels wrong, it probably is. And although gut feel / intuition can play a small role in estimating some estimates, there is no room for wild guesses that aren’t based on anything. A better approach than gut feel is estimating by analogy. This refers to estimating something by comparing to some other, similar thing with which you are more familiar. A good technique when estimating is to triangulate estimates. This refers to comparing the item being estimated to two, or occasionally more, items that have already been estimated. These comparisons often to one item larger and one smaller than the item being estimated can help indicate if an item i...

Following is my rough notes from Mike Cohn’s Agile Estimating and Planning Course  which I strongly recommend. I hope you will find some useful sentences within the lines. Task Dependency Task independence Tasks are not independent in Software Development Central Limit Theorem (CLT): The sum of a number of independent samples from any distribution is approximately normally distributed. According to the CLT, If tasks are not dependent on each other we can say that if the first independent task "A" takes %50 longer, depend on this we cannot say the other ones would take %50 longer, too.  But if the following tasks "B" and "C" are dependent on "A", and if those are similar tasks with "A", we can say, or should expect, that "B" and "C" are also take %50 longer than expected. Student syndrome “Starting a task at the last possible moment that does not preclude an on-time completion.” ...