Posts

Showing posts with the label Release Planning

Fixed Price Project

Image
Someone said : “I want all of this by that date” This type of project is generally considered the hardest to manage. There are two type of this kind of project. You are given no choice. This refers to the cases when someone has literally dictated both date and scope. First assess the risk trying to do everything by the given date. Next decide to do the project or not Second type of this project is when you have some flexibilty. Again start by assessing the risk. And then try to balance the scope and schedule risk equally. Example : You can calculate easily the values above.  Check this to see how you can find the velocity range.  So at this point you should discuss and choice a scope-based option “200 points in 11 iterations” or a date-based option “180 points in 10 iterations”. See also fixed-date planning and fixed-scope planning References frontrowagile.com/courses/agile-estimating-and-planning

Fixed Date Planning

Image
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...

Simple Release Planning with Historical Velocity Data

Image
Lets assume that you have 26+ past iterations to calculate velocity and there are 5 iterations left to finish product backlog. So how many backlog items can you do until the end of the project? Velocity Calculation Steps - As per the table below you should throw out 8 best (highest) and 8 worst (lowest) velocitiy values We throw away outlying values because those values are unlikely to be the team’s future average. The range that remains after throwing away some number of outliers represents a confidence interval around the team’s future velocity. - And then you can determine true velocity in the range between 36 and 41 with %90 level of confidence as follow.  This method is based on an statistical technic known as “Confidence Interval Around the Median” using a binomial distribution. So in this case you can make the product backlog planning as follow References https://www.frontrowagile.com/courses/agile-estimating-and-planning ...

Estimate By Analogy

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...

Agile Estimating and Release Planning

Image
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.” ...