Re: Bob Schatz in Mechelen: The Sprint Review is for the End-User.
- Well Boris, it sounds good, but of course (like everything in Scrum) it is context dependent.
If you are building some bespoke software for a small company, then sure, have the user of the system there. If you are building a web portal for 10,000,000 people that gets a little harder. You can have a sub-set of maybe 5 or 6 users there, but they are then just proxies for the other 9,999,9995. The Product Owner is a proxy too. Part of his/her role is to be in tune with the end user as well as the customer.
Where possible the team should also be in touch with end users, but again that is not always practical. I have sat in on focus groups which supposedly represent "typical users" and they are often a waste of time.
I would suggest the Sprint Review is actually for the customer: the person who is footing the bill. It is, of course, the customer's responsibility to know the needs of the end user, but even if he does not, he is the one paying the bill so ultimately the one who will sign off on the work.
The faster we release software the faster we'll get real user feedback. That should be the aim. The review is the decision point to decide whether users should or should not see a particular increment of the product. Sometimes the PO is the right person to make that call, sometimes it is the customer.
--- In firstname.lastname@example.org, Boris Gloger <boris.gloger@...> wrote:
> I had the pleasure to run a class together with Bob Schatz in Mechelen
> this week. We had a full house, a lot of fun and a lot of very good
> questions. One answer of Bob I will always remember:
> The Sprint Review is for the End-User. Not for the Product Owner not
> for the Management. You need to have him there.
> I strongly support this statement because I believe we need to talk in
> Scrum about 6 roles:
> The User, the Customer, the Manager, Product Owner, Team and
> We are this week in Oslo. Bob will be in Europe soon - check our
> website: www.sprint-it.de
> Scrum - Produkte zuverlässig und schnell entwickeln
> You've been invited to view an album on .Mac Web Gallery.
> Bob Schatz in Mechelen
> I published an album to my .Mac Web Gallery that I'd like to share
> with you. To check it out, click View Album.
> If you are unable to access this page, please copy and paste the URL
> below into your browser.
>OK, the poor pigs and chickens have had their time. Instead ofThere are elements of Scrum (and Agile in general) that address the
>interpreting Boris' post in a 0/1 perspective, I would like to extract
>the valuable information and try to fit it into the Scrum framework.
interaction of the Team with the End Users. The approach that we use,
which I believe is essentially what Ken describes in the book, is that the
programmers sit down with the actual users and discuss what they need. I
believe that in a large part, this is what items 1 & 3 of the Agile
Manifesto are talking about.
From that perspective, we treat the End Users as "resources" and not Team
members. It would be different if they were on the project full time,
We also do the same thing with our web developer. He spends most of his
time doing content changes and independant development. When we need him
to do some work on something more involved and related to core systems, we
usually only need a day or two of his time. So the Team's BA takes
responsbility for his involvement, makes sure that he understands what's
needed of him, and reports on his progress at the daily stand-up meeting.
I think the biggest point to keep in mind is that you want to keep all of
the distractions away from the Team if you can. This were the SM really
earns his paycheck. If there are issues with the PO not talking to the End
Users, or taking the project in the wrong direction, or whatever, then it
really is up to the SM to be on top of those things and sort them out. The
Team may notice them first, in which case I would expect them to be raised
as impediments at a scrum, and then the SM is supposed to take it from
there and stop it from further distracting the Team.
So as far as implementing Scrum goes, I'd pretty much lay it all on the SM.
He's the one who's supposed to understand how it all fits together, and
he's the one that the Team needs to count on to make sure that it is, in
fact, fitting together properly. The idea is to make sure that the needs
of the chickens are looked after, but at the same time keep them from
distracting the Team.