Salakhetdinov Shamil
mcp2004 at mail.ru
Fri Mar 20 10:14:55 CDT 2009
Hello Mark and SCRUM Team Members, Thank you for your questions Mark. Here are my answers: Question 1: Yes. Question 2: Yes :) Question 3: I think we're ready now - please use http://smsconsulting.spb.ru/scrum/nwbl.zip to split ProductBackLog into 3 SCRUM Sprints: 1st: 43 "evaluation points" long (2 weeks) 2nd: 22 "evaluation points" long (1 week) 2nd: 22 "evaluation points" long (1 week) (in reality that Sprint planning is more through procedure but let's try to make it light here this time and see how it will work) Please feel free to skip the following lengthy explanations and maybe just read the referenced in P.S. SCRUM methodology stuff. According to my current understanding of SCRUM practices ProductOwner can't communicate directly with team on issues why this or that ProductBackLog position "weights" this or that much. I'm giving references on the SCRUM methodologies' entries below for you and our SCRUM team members to check my understanding. Please read them (they are in total words not much longer than your e-mail), and I think then you will be able to answer your questions by yourself. If not, please ask them again or ask the new ones if needed - and we will try to come to the common ground - SCRUM isn't a "new religion" but a constantly improving methodologies/practice of agile software development... I must say I was not very strictly following SCRUM methodology proposing to the team members to evaluate ProductBackLog items in "ideal hours" - "ideal hour" term is from XP/agile but in SCRUM ProductBackLog items are estimated using abstract "measuring units": one can use "kilograms", another one "pounds", third one "liters" etc. I asked to use "ideal hours" to just "get it(estimation) done" as quick as possible because everybody usually estimate possible workload in time measuring units: hours, days, months... We need something for starters - later on when we will have some statistics on our performance (SCRUM team velocity) we will be able to estimate using more abstract "estimation points"... If everybody interested I can "open my secret" how I did estimate our project BackLogItems - I can say now that this estimation wasn't using directly time related measurement units IOW it could have been wrong in many positions: as you can see my estimation was rather close to Mike's one and is about 20% lower than average we plan to use (as everybody agreed?) as our max time frame. I just wanted to tell that if we estimate now that FormA "weights" 3 "ideal hours" or "kilograms" and FormB "weights" 1 "ideal hour" or "kilogram" then when they will be implemented it may happen that it was spent 1 real hour (or half an hour) to develop FormA and 3 (or 3.5) "real hours" (or "kilograms" of bananas eaten while developing this form?) but they were *done* within one SCRUM sprint, and this means (if nothing else was done) that SCCUM team velocity is 4 ProductBackLog "points" per SCRUM sprint (SCRUM sprint usually takes 1 to 4 weeks). Using that statistics we can plan the next SCRUM sprint (usually statistics for the last 5-8 Sprints are used during next Sprint planning, or statistics of the less "speedy" Sprint, most "speedy" Sprint and one from the "middle speed" for the last 5-8 Sprints... Am I clear enough about this SCRUM evaluation and Sprints planning? If not please ask more questions and I will try to answer them by myself and by giving some more references to read. I must say this is the first time I'm explaining/trying to explain that subject here - IOW we all are learning by doing here now. I have seen how it works in practice but that weren't software projects we used to implement during CSM course. But my SCRUM Trainer used similar SCRUM practices with SCRUM Teams in BusinessWeek and Yahoo and they worked well for them... I'd also propose for us to have 3 SCRUM Sprints during the coming month: 1. 2 weeks long 2. 1 week long 3. 1 week long And I'd suppose/expect that first 2 weeks long SCRUM Sprint should be considered a success if we will make as many "evaluation points" during it as we will do during the shorter 2nd and 3rd one... When you will read the referenced below short articles on SCRUM Sprint planning you will find that ProductOwner communicates with the team while getting to be developed items into next Sprint area/plan and asking team can it be done within that Sprint or not - team can agree/commit to do it or can reject but ProductOwner can't "push" on team and ask why they think they can't do that item if it "weights" say X "ideal hours" and there is still a room in the next Sprint for that item to be done. Here is where SCRUMMaster should take his facilitating role/position to negotiate such ProductBackLog positions with team but without the presence of ProductOwner... All in all ProductOwner does and should communicate very closely with the SCRUM team and he/she has the whole picture of the project progress as in real life case team velocity is measured and published every day based on completed (DONE) Sprint items. But ProductOwner is "forbidden" to push the team, to ask "provocative" questions, to change Sprint items during the started Sprint etc. - this is how I understand these SCRUM practices... I should also note that in real life ProductBackLog items are also getting split into tasks during Sprint planning phase - we're not doing that split now because of our distributed in time mainly offline way of working, and because most of ProductBackLog items beeing rather clear to everybody... And I should also note/underline that SCRUM team velocity is measured only using "Done" (accepted) ProductBackLog positions - if a position is 99.99% "done" it isn't used in calculating SCRUM Team velocity... Mark, knowing your ability to summarize very well I expect you will come here at dba-VB with several sentences summarizing what I have written above and what I have referenced below, and answering very shortly your own questions. Please if you do not have any more questions to discuss put the first set of items from this ProductBackLog (http://smsconsulting.spb.ru/scrum/nwbl.zip ) into first 2 weeks long Sprint. This Sprint is expected to "weight" max 5*5*2 = 50 "evaluation unit points". Please leave some free room in it - let's say 10%. Please note that if the SCRUM team will manage to do 50 points within the first week or first week and the half then this is OK to add more ProductBackLog items to be done (or started) within the first Sprint. But the more probable result will be we will not fit the first SCRUM sprint ProductBackLog - no problem if that will even be half of the backlog not done as this usually happens with new teams. The problem/issue will be when we will not manage to make all ProductBackLog implemented during the whole month long project within three Sprints. Well, I'm wiring "problem" but let's keep it easy here as this is more fun than real work what we're doing here - a SCRUM Club as dba-VB where we all are learning the new things, which are supposed to work well in real life projects we're doing for money+. I'd also propose to measure our team "daily velocity" using every week results as every week should take 5 hours of work of every team member - let's call these 5 hours "a working day"+ If we will be "equally speedy" during all the four weeks then our team velocity will be 87/4 = ~22 "evaluation points per working day" , and we can use these stats while planning other projects, and you as the ProductOwner will know that all is "transparent and clear here" - and SCRUM team is doing their best+ Thank you. -- Shamil P.S. Scrum Effort Estimation and Story Points http://scrummethodology.com/scrum-effort-estimation-and-story-points/ "In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on velocity the team's velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Thus it is recommended that the Product Owner does not observe the estimation process to avoid pressuring (intentionally or otherwise) a team to reduce its effort estimates and take on more work. Even when the team estimates amongst itself, actions should be taken to reduce influencing how a team estimates. As such, it is recommended that all team members disclose their estimates simultaneously." SCRUM Meetings http://scrummethodology.com/scrum-meetings/ "At this point, the Product Owner is typically asked to leave while the team decomposes the sprint backlog items into tasks. While the Product Owner is asked to leave so that the team can candidly discuss the work, he or she is still expected to be "on call" to answer questions, clarify acceptance criteria, or renegotiate. This meeting, which was previously called the sprint definition meeting, is also time-boxed to four hours to limit all sprint planning activities to a single day's time." SCRUM Impediment http://scrummethodology.com/scrum-impediments/ SCRUM Product Owner http://scrummethodology.com/scrum-product-owner/ The ScrumMaster Role http://scrummethodology.com/the-scrummaster-role/ -----Original Message----- From: Mark Breen <marklbreen at gmail.com> To: Salakhetdinov Shamil <mcp2004 at mail.ru>, "Discussion concerning Visual Basic and related programming issues." <dba-vb at databaseadvisors.com> Date: Fri, 20 Mar 2009 09:41:31 +0000 Subject: Re: [dba-VB] [AccessD] SCRUM: Northwind .NET Product BackLogPlanningGame... > Hello Shamil, > I have one or two questions on scrum techniques. > > In the estimates, the product owner has to make some judgement calls on > which items to drop, and which items to include. Or let me phrase that > better, the product owner has to prioritise his importance of the items, in > the hope that he receives all, but if he does not, then he must decide which > items to exclude. > > Background of question first > My personal instinct, and the behavior of most people I know will be to seek > some additional information from the 'supplier' as to why feature a takes > one hour and feature b takes 5 hours. I would expect that most people > would assume that this background information assists them in their decision > process, as they are making it from a position of knowledge. Also, as a > product owner in this case, I imagine that there is a certain element of > risk / gambling on the product owners behalf, i.e. do I place this feature > (a 5 hour estimate) at the top of the list, and guarantee its delivery, or > do I drop it down the list, and guarantee five other (1 hour) features. My > instinct at this point is that most people will desire a little background > on the justifications for why one item is one hour and one item is five > hours. > > > Now the question to our ScrumMaster > In this new world, is the above appropriate thinking on behalf of the > product owner. Do I / should I re-program my brain to accept blindly the > estimates and focus only on what is important as a delivered feature and NOT > on why feature A takes five times the time to produce feature B. If I take > this blind leap of faith, will I eventually produce more accurate views on > what is important to my business? i.e. should the product owner keep their > nose out of the programmers area and stick to being product owner. > > > Question 2 > In a larger project than this one, but even in this small project there are > synergies, IOW, the work to produce the suppliers form, may be identical to > the work to produce the categories form. Should the product owner know > there there is some virtual grouping here? Or once again, should he keep > his dirty nose out of these types of concepts. I think you answer will be > yes, he should keep his nose out and leave that to the scrum team. > > Question 3 > When are we ready for me to prioritise the list > > > > > < snip>