About Scrum

This was really well done and engaging. However, there are three serious inaccuracies that I would urge you to correct.

1) It is vitally important that the product backlog (which you are referring to as the release backlog) be prioritized by the customer (or customer proxy), to ensure that you are always working on the most important stuff.

2) You do not break a release backlog into sprint backlogs. Rather, enough items are pulled off of the release backlog to fill the sprint. At the end of the sprint, new items are added to the release backlog based on customer feedback from use of the software developed in the sprint, and the backlog is re-prioritized.

THE ABOVE FEEDBACK LOOP IS ESSENTIAL TO THE SUCCESS OF SCRUM PROJECTS.

3) You do not create a defect backlog. Defects become new stories for the product (release) backlog and get prioritized along with everything else. This ensures that the team is always working on the most important thing (whether its a bug or a feature).

I also found this video very interesting for people learning Scrum.

I agree with the first two points highlighted by Curt, but I can't with the third:

From what I think about Scrum, a defect should not become a new story. Imagine: the customer already paid for a story to be completed in a particular sprint and later detects a bug. Why should he pay again to get this defect fixed?

For me, a bug becomes the most important item in the new sprint and will be fixed *before* any other story.

I also miss another very important item in Scrum: the Retrospective. It's the most important process step for the team to improve their velocity by eliminating their impediments.

I second Curts advise regarding defects.

The Customer will pay for the resolution of the bug, whether it is managed in the product backlog or not. You should put it into the product backlog, because it is the Product Owner's decision if the team should work on the defect immediately or not. Sure, the team should "educate" the PO that the later a bug is resolved, the more expensive it will be, but prioritization is the job of the PO.

A defect in the Product Backlog won't have Story Points assigned and thus does not "earn" velocity (this matches somewhat Christians statement: the customer "paid" already for it, or in other words: the team already got credit for the feature and won't get credit a second time).

And: If you have to think so much about defect management, then you have a deeper problem. I don't like the attitude in the video that bugs are unavoidable. You/the team team should strive for defect-free software - otherwise you will have to manage your defects ;-)

YMMV, of course.

Is there a direct link to download? we want to pass it away and it's hard to DL it every time.

Hi All,

I will support Christian on this

Firstly, the story is deemed not complete if there are defects raised on that story. There is no rocket science in this..its common sense, else why do we need to get testing done for each story.

Secondly, from the tester view point, he or she cannot get their scripts done for that particular story, thus in effect not getting the story tested in furture releases which effectively beats the whole purpose

However I also think that the severity of the issue should play an important role in the decision.

Thanks..

I thought this was a great video! Nice,simple description....I'll agree with Curt on the issues here, but I know there are variants, so, good job!

So, I am curious. If you don't advocate the daily stand up on "experienced" teams, what is your position on demo, retrospective and planning meetings?

Hey Hamid, long time. Things are good, man.

I came across this video and thought it was nicely done. Nice work.

The only thing I'd be careful about is that new folks might view this video and take away that daily stand ups are optional, and if they are, then demos/retros and planning meetings can be skipped as well.

Probably not your intent at all, but as a Scrum/Agile trainer, coach and mentor, the most important thing I strive to teach new teams is that discipline is absolutely critical to being succesful with Scrum, regardless of what tools they may use.

I like to use Shu-Ha-Ri to describe the levels of learning. When you are new to Scrum, do Scrum by the numbers - Shu.

If you do this, Scrum will become natural, like breathing- Ha.

Once you have reached Ha, then *maybe* look at tweaking things- Ri, but I don't know many people who feel comfortable saying they'e learned all there is to know about Scrum. I certainly haven't.

This video is amazing, specially for starters in Agile and who wants to know about what Agile is.

Great video and comments from all with regard to handling defects. I can see both sides of the argument. Good info for a scrum newbie like myself.

Any chance getting this video as an MPEG instead of on youtube. People at work can't see youtube.com....blocked in general.

test

Video & Audio are not in sync: When you click on the video progress bar to previous slides from then on only the audio plays at the present position but the video doesn't have any effect on its way.!!

Who will evaluate the performance of the team member?

If the answer is Scrum Master, Does he involves in desgin aspects and Technical aspects before the sprint starts.

I'm new to this and find it exciting. Great presentation Hamid. I found Curt's comments to be good and can see both sides of the coin on defects. My experience is that the customer will sometimes change their mind on what is really important when they get interim releases and may decide that fixing a particular bug is less important than working on a "new story" (never heard that term before) that is not bug related. Customers, like software engineers, don't always get it right the first time and they only realize that when they start playing with the interim releases.

I have a question for this group. Do you ever have any trouble getting the customer to play with the interim releases? For the early releases it seems possible that there may not be enough "system" or "infrastructure" working to make playing with an interim release very easy, so the customer might be tempted to blow off playing with early releases. Has this been a problem in anyone's actual customer experience?

Open this video in IE. Install Real player and download this video. Simple

Open this video in IE. Install Real player and download this video. Simple

Great video and narrative, but I found the background music grating and distracting. A version without the audio loops would be nice to have.

Apart of the few issues raised by Curt & Christian, the presentation is good and self explanatory. Clarified my concepts on scrum.

Thanks Hamid.

Hamid, It's great and exciting.

Would you please, post the text of the speach, in order to translate it to all members of the group.

Thanks.

Cool,

thank you so much for theat video tutoial..

Thanks

Though I am a agile team member, I liked the video very much and instatly shared among the team members but we thought that if more information can be provided on SBL (Spring BackLog) and applications can be used for that (Ex: Excel) would be more useful.

To learn scrum about the need to run a little head ;)

saolasin dostum