Topic Text   Topic Comments (0)   Topic Properties   Topic Information abc@def...
Topic title: AQ Test Topic1 Monday March 8, 2010 23:36:04

Download topic text | View in variable-width font | Tab width set to 4 (change to 8)

Files in topic:  
[Jump to] Dev 317 - Agile Estimation.rtf   {+69,-0}

[Add General Comment] to topic.

File Dev 317 - Agile Estimation.rtf (Revision 1.0) [Add File Comment] [Top]
 
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
 
  
Legend:
Removed 
Changed
 Added

[Add General Comment] to topic.