19. Experiment within a specific time with the objectives of estimation - Spikes
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
Editor's Notes
Human’s capability to design without feedback is poor. Typically large upfront requirements and design will typically changeKey is to find that right balance – finding that balance differ from person to personIdea is start coding at the right time, so requirements can be
Customer team : Product Management, user ( if possible actual user ), testerCustomer PrioritiesDesirability from a broad base usersDesirability of the feature to a small number of important usersCohesiveness Developer PrioritiesTechnical riskCohesivenessStandupMeeting – think about a maximum of 3 things the team like to know about your work
Epic – very large stories with a large value for estimatesUser stories emphasize verbal rather than written communicationComprehensible by both you and the developersRight size for planningUser stories defer details until you have the best understanding about what you really need-> Stories can contain stories, just describe a large story and rip it up later splitting it to multiple stories
How much details is enough? The notes on the card is not important, it’s just to be a reminder, if you can remember don’t put it in.There are details that developers already think they know, it’s important that developer don’t assume – have the conversation and jot things down, don’t get too much detail, start coding first and get the feedback
Who:Customer teamWhen : During conversations between customer + developer and want to capture explicit detailsDedicated effort at the start of an iterationAfter programming of the storyWhat :-What else do the programmers need to know about this story-What am I assuming aout how this story will be implemented-What are the circumstances when this story may behave differently-What can go wrong during this storyFunctional in nature but possible to include ui flow, usability testing, performance testing, stress testingHow Needs to be automated – see fitnesseTesting for bugs not coverageAdd a test for each bug
Stories may not be independent initially, if
Issues, since there will be multiple gateway, the developer spend an upfront design and development for the base components and then provide the specific implementation and testing for each of the gateway
Epics fall into two types : Compound-split but retain cohesivenessComplex – pull research away from functionalityEg. complex algorithm, complex business process
Needs to be testable
Tools : Role ModelingCustomer Team
Constantly adjust plan to reflect the knowledge we gain from each iteration
Can be the 3 hours of solid work half dayCan be the ideal 8 hour work day, etc.Can be the 3 hours of solid work half day of two developers
Not every developer are the same – different backgroundsEstimating as a team levels outEveryone tries to complete as a team – prefers completing stories over starting new ones, Organization Development
Time Select iteration length Time to completePrioritizationBroadbase usersImportant usersCohesivenessCustomer Team Prioritizes with the help of the team
Personally I think upfront design is essential to be efficient, finding out the right balance is important – it should be allocated and the amount of time spend should be short – the longer the more complicated