| |
| 1 |
{\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset0 Calibri;}{\f1\fnil\fcharset2 Symbol;}} |
| 2 |
{\*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\b\f0\fs22 Dev 317 - Agile Estimation\par |
| 3 |
\b0 Stephen Forte (Telerik cheif strategy officer) - Stevef@orcsweb.com\par |
| 4 |
\par |
| 5 |
\pard{\pntext\f1\'B7\tab}{\*\pn\pnlvlblt\pnf1\pnindent0{\pntxtb\'B7}}\fi-360\li720\sa200\sl276\slmult1 Problem is that estimates become unbreakable schedule where any deviation is bad\par |
| 6 |
\pard\sa200\sl276\slmult1 1 month estimate requirements \par |
| 7 |
4 months dev \par |
| 8 |
1 month testing\par |
| 9 |
\pard\sa200\sl276\slmult1 requirments late by 1 week..\par |
| 10 |
you then need to up dev estimate by a factor of 25%\par |
| 11 |
\par |
| 12 |
\pard{\pntext\f1\'B7\tab}{\*\pn\pnlvlblt\pnf1\pnindent0{\pntxtb\'B7}}\fi-360\li720\sa200\sl276\slmult1 First estimate is often off by a factor of 4. Look up on google Steve McConnel the cone of uncertainty... as time progresses our estimates improve (get more accurate) more information is available\par |
| 13 |
{\pntext\f1\'B7\tab}Agile estimation always re-estimates a project after each iteration\par |
| 14 |
\pard{\pntext\f1\'B7\tab}{\*\pn\pnlvlblt\pnf1\pnindent0{\pntxtb\'B7}}\fi-360\li1080\sa200\sl276\slmult1 Different value system, devations are not deviations they are more accurate estimations\par |
| 15 |
{\pntext\f1\'B7\tab}Use the cone of uncertainity to your advantage\par |
| 16 |
\pard\li360\sa200\sl276\slmult1\par |
| 17 |
\i How to Estimate \i0\par |
| 18 |
\b\i User stories \b0\i0\par |
| 19 |
Different way to gather requirements- gets the business involved really early and adds buy in to the process. \par |
| 20 |
Users write a story about how they peform a function. Kept small. Few bullet points. Need to sit with users to try and keep the stories short and relevant. \i Must get the acceptance criteria - this becomes the test criteria. \par |
| 21 |
\i0 example : Create a login screen would be an example of a user story.\par |
| 22 |
\b\i Planning Poker\b0\i0\par |
| 23 |
Get a list of stories and do a high level estimate - for setting priorities, not schedule.\par |
| 24 |
NOT a time based estimation, it is Super hard, Hard, Medium, Easy , Super Easy \par |
| 25 |
This is done by consensus. Just like playing poker. There should not be any any pressure at this point. \par |
| 26 |
\b\i Story Points \b0\i0\par |
| 27 |
Break down user stories to units of \i relative\i0 size. This enable you to compare features - alternative to time.\par |
| 28 |
Story points are not a measurement of duration, but if complexity.\par |
| 29 |
\par |
| 30 |
\b\i Product Backlog\par |
| 31 |
\b0\i0 All story points are put into a bucket\par |
| 32 |
This represents the tasks for the project\par |
| 33 |
Backlog will have an item and estimate (complexity based, not time based)\par |
| 34 |
\b\i Sprint 1 \b0\i0\par |
| 35 |
Developers will commit to xx story points\par |
| 36 |
Warning, they usually over commit\par |
| 37 |
After the end of the sprint 1, you have your first velicty number\par |
| 38 |
Note : any story not completed is returned to the pot...\par |
| 39 |
Any bugs found are also added to the product backlog\par |
| 40 |
Any additional stories added go into the product backlog\par |
| 41 |
Each sprint should be deployable....\par |
| 42 |
\b\i Team Velocity\par |
| 43 |
\b0\i0 Velocity is the number of story points per sprint completed\par |
| 44 |
\ul\b\i You calculate velocity to predict how much work to commit to a sprint\ulnone\b0\i0\par |
| 45 |
Any holidays need to be allowed for ..... google it\par |
| 46 |
At the end of each sprint, velocity will change\par |
| 47 |
\b\i Re-Estimation\b0\i0\par |
| 48 |
Will usually stabalize between 3 & 6 iterations\par |
| 49 |
Re-Estimate of the entire project happens after each sprint\par |
| 50 |
New velocity\par |
| 51 |
New story points added or removed(completed)\par |
| 52 |
Use the cone !\par |
| 53 |
Users will re-prioritise the backlog.. \par |
| 54 |
\par |
| 55 |
\b\i Notes : \par |
| 56 |
\i0 Infrastructure concerns also need to be estimated...\b0\par |
| 57 |
Developers need to write a user story to do this and this would need to take top priority... and be completed as part of the first sprint.\par |
| 58 |
\b Need to create a baseline \par |
| 59 |
\b0 In order to create a baseline for initial poker you must have a baseline. Get the dev team to do some development for a couple of days to establish a baseline for dev complexity .... \par |
| 60 |
\b Never let the business allocate more work than the current team velocity \b0\par |
| 61 |
If work is finished early, go back to the business and get them to choose another item that can fit in to the available time... This way velocity can be increased.\par |
| 62 |
\b How to deal with dependancy\b0 \par |
| 63 |
If an item is dependant on another, then set the required item to a high priority and set the other item to medium.\par |
| 64 |
Useful resources \par |
| 65 |
User Stories Applied - Mike Cohn\par |
| 66 |
Agile Estimating And Planning - Mike Cohn\par |
| 67 |
Agile Retrospectives - Esther Derby & Diana Larsen\par |
| 68 |
} |
| 69 |
� |
| |