Starting scrum: what would be the logical position of classic PM? SM or PO ?
nela
what role in Scrum would be the best to go into?
If I want to now start with Scrum, which role would be, in your
opinion, the best for me, and others like me?
Thanks,
Nela
Mark Levison
Cheers
Mark
Ahmed Nasr
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
--
Best regards,
Ahmed Nasr
--------------------------------------------------------
Ron Jeffries
wrote:
> i'm with the opinion of what fits you best, but i have another opinion that
> PM could be PO, and scrum master is more for the persons responsible for the
> process.
The Product Owner needs to be a domain expert, and needs to be in a
position to be responsible for delivery of a successful product. The
Product Owner does this almost solely by managing scope. At least
some Project Manger types would find this hard to do.
I agree with those who say learn about Agile, preferably experience
it, and then decide.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Knowledge must come through action;
you can have no test which is not fanciful,
save by trial. -- Sophocles
nela
projects so far. Now, I am given a green light to run my next project
with Scrum. But I have to organise it myself. The question is the
roles. And my pool manager is not sure yet, and it seems to me he
leaves it to me.
What I am trying to say, I do not have the time to experience it and
then decide. I have to decide in Jan/Feb , when the actual start of
the project will be. ...
Regards,
Nela.
My project is a pilot project in the company, and
nela
My project is a pilot project in the company, which means, I will be
the only one running a project with Scrum. Like a test-project, to
convince managers to use it more and more.
I have to do the classic Pm stuff anyway, enter the PDs into a project
plan, create tasks and subtasks, people then book their time on
certain tasks, I have to budget for the PDs and for the extra costs
like licences and hardware, plus of course the monthly reports to
Steering Committee, etc etc.
That does not take too much time, but that is what I meant when I said
- classic PM.
bye!
Nela.
Marc Bless
(didnt finish the sentence, sorry:)
My project is a pilot project in the company, which means, I will be
the only one running a project with Scrum. Like a test-project, to
convince managers to use it more and more.
I have to do the classic Pm stuff anyway, enter the PDs into a project
plan, create tasks and subtasks, people then book their time on
certain tasks, I have to budget for the PDs and for the extra costs
like licences and hardware, plus of course the monthly reports to
Steering Committee, etc etc.
That does not take too much time, but that is what I meant when I said
- classic PM.
Peter Hundermark, CSC, CST
As Ken has said many times, the responsibilities of the traditional PM
are split across all three Scrum roles:
- the PO manages the product,
- the SM manages the process, and
- the team manages itself.
As Ron has already pointed out, it is essential for the PO to possess
domain knowledge, which will preclude some PM's from executing this
role.
The SM role requires its occupant to act without authority over
anything but process and exercise servant leadership. Some (many?)
traditional PM's will struggle with this. Yet for some, this is how
they have led people before. They will still need to give over some
responsibilities to the PO and the team.
A few more comments in-line...
On Dec 24, 3:56 pm, nela <nela.soldatovjo...@gmail.com> wrote:
>
> I have to do the classic Pm stuff anyway, enter the PDs into a project
> plan
This is PO work
> create tasks and subtasks
This is the team's work
> people then book their time on
> certain tasks,
This is no longer required at all. Just count the cost of the whole
team per sprint and distribute it over the features they deliver is
some simple fashion. You could use the story size, if you are
estimating, or just a simple division of cost by number of features!
> I have to budget for the PDs and for the extra costs
> like licences and hardware, plus of course the monthly reports to
> Steering Committee, etc etc.
This is all PO work
> That does not take too much time, but that is what I meant when I said
> - classic PM.
I would suggest you need to get the appointees to the roles to own
their respective responsibilities. I think it's OK to coach them into
doing this if they don't yet possess the skills. But it's not OK to
continue to to the work. The transformation you seek by introducing
Scrum will simply not happen if you do. Scrum is disruptive of the
status quo by design...
Good luck!
Peter
George Dinwiddie
nela wrote:
> I have to do the classic Pm stuff anyway, enter the PDs into a project
> plan, create tasks and subtasks, people then book their time on
> certain tasks, I have to budget for the PDs and for the extra costs
> like licences and hardware, plus of course the monthly reports to
> Steering Committee, etc etc.
> That does not take too much time, but that is what I meant when I said
> - classic PM.
None of this sounds like stuff that's needed on an Agile project. I'm
not sure what you mean by "PD," but a Scrum release plan is a pretty
simple thing and belongs to the PO, in my opinion. Deciding the tasks
and subtasks and who does what belongs to the people doing the work.
Budgeting still exists, as does reporting out to upper management--it's
not part of the Agile process, but is part of being in the organization
that expects such.
None of this seems to help you find your place in a Scrum project. What
else do you like to do?
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
nela
Thanks a lot for all your replies, very helpful indeed.
So, let me clarify /comment:
"None of this sounds like stuff that's needed on an Agile project."
My company allowed me to use Scrum, but only together with what they
already use. So, I have to incorporate it. In other words, I will
still be the "single wringable neck" to them, and they want me to
report to them regularly. In their little databases of all the
projects in the company, my project is just one of many, and they will
call me the project manager anyway. They do not use Scrum officially
yet, so they do not wish to change their ways.
-----
"But it's not OK to continue to do the work. The transformation you
seek by introducing Scrum will simply not happen if you do. Scrum is
disruptive of the status quo by design... "
This sounds to me like, if I am not able to convince the big-wigs to
use Scrum and Scrum only, I will not succeed :-(
-----
"Budgeting still exists, as does reporting out to upper management--
it's not part of the Agile process, but is part of being in the
organization that expects such. "
Well, this is all it is - really, they only want me to send reports,
and inform of changes in budgets and PDs (PersonDays) on a monthly
basis. So, even if I end up a SM in this particular project, I could
also do this ? The problem is the peculiarity of this company's
project-running system. I know it very well for some years. So, they
trust me to do it. The potential PO in this new project who knows more
about the subject matter to be developed, he hasn't got a clue yet
what needs to be done as a project manager, in this particular
company. But he knows and understands the project matter.
-----
"The SM role requires its occupant to act without authority over
anything but process and exercise servant leadership. Some (many?)
traditional PM's will struggle with this. Yet for some, this is how
they have led people before. They will still need to give over some
responsibilities to the PO and the team."
Responsibility is the key issue here: to my immediate managers, as
well as all the way to the top management, I am and will be the only
responsible person for the whole project, Scrum or no Scrum. They
really don't want to hear the word Scrum - let's say they are not
interested. That is my internal issue. So, now if I want to do it with
Scrum I have to delegate that responsibility and watch the PO like a
hawk? (in this respect it seems also logical that I could be a PO)...
Another way, it seems to me, that I can let the PO do the work - but I
monitor it and then I stay the only responsible - for this first
"pilot Scrum" anyway. It will have to change for the next project...
-----
"The Product Owner needs to be a domain expert, and needs to be in a
position to be responsible for delivery of a successful product. The
Product Owner does this almost solely by managing scope. At least some
Project Manger types would find this hard to do."
I would like to think that I would not find it hard to do, as I
usually get involved with the actual project issues. This time I have
not gone deep into it yet, it hasn't started yet, but my head analyst
has finished the list of features to be included, connected, etc etc.
So, I would need to look into it with more attention. In my previous
projects that were not run using Scrum, I was always in a position
responsible for delivery of a successful product. That would suit
me. ...
-----
and finally...
"Who decided to run a Scrum pilot project? "
My head architect, he heard about it, never done it, and suggested it
on our first kick off meeting. I then started reading about it online,
I was talking about it to the team members (who all seemed very
enthusiastic) including this architect and my pool manager. And in the
end - I was told that it was my decision as a PM: shall we go with
Scrum or not. And I said: ok we go with Scrum. Then my pool manager
sent 14 of us to the SM Training, this December. He also went higher
up the management, to suggest a pilot project run by me with Scrum,
and is it ok with them. So, the top-management said OK, and that was
that.
After the training, my pool-manager decided to have another meeting
end of January with the SM Trainer, to talk about our company internal
procedures and how to fit them with Scrum, etc. Hopefully, that would
tie the loose ends and answer many internal questions. I will also be
present at this conversation.
You gave me a lot to think about, I am very glad adn very grateful! I
will also check the links online that you suggested.
Thanks a lot again!
Greetings and Merry Xmas!! (even if it is a bit late)
Nela.
Cory Foy
I'd like to combine some of your points, slightly out-of-order from how
you wrote them:
nela wrote:
> The potential PO in this new project who knows more
> about the subject matter to be developed, he hasn't got a clue yet
> what needs to be done as a project manager, in this particular
> company. But he knows and understands the project matter.
So, here's the rub. You have your Product Owner identified. But, you
also have your Project Manager defined - and it's not who you think it is.
The sole responsibility of "project management" is the team's - not yours.
> They
> really don't want to hear the word Scrum - let's say they are not
> interested. That is my internal issue. So, now if I want to do it with
> Scrum I have to delegate that responsibility and watch the PO like a
> hawk? (in this respect it seems also logical that I could be a PO)...
> Another way, it seems to me, that I can let the PO do the work - but I
> monitor it and then I stay the only responsible - for this first
> "pilot Scrum" anyway. It will have to change for the next project...
From what you've told me, you are better off as the ScrumMaster - but
be cautious.
Being a single wringable neck means that you are under pressure to
ensure the project is completed. And that's the problem - *you* are
under pressure. Which means that when the pressure is applied, you will
be expected to resort to traditional Project Management techniques.
But that's not Scrum - or agile - at all. Those reports you mentioned?
Those spreadsheets? The PDs? That's not your responsibility - it is the
team's. So what you should be doing is sitting with the team, explaining
*all* the deliverables you need (you *are* counting those reports as
deliverables, right?) and then have them design a solution for producing
the reports.
Now, that solution might be for them to ask you to do it. But ultimately
it is their responsibility for making sure it is done.
This is why it can be challenging to implement Scrum in organizations
which maintain a traditional PM mindset.
> This sounds to me like, if I am not able to convince the big-wigs to
> use Scrum and Scrum only, I will not succeed :-(
You may succeed, but only at a local level. Which is OK if you are a
self-contained unit. What generally happens is that Scrum gets
introduced through the back door, and the team does well, then they
start running into organizational constraints out of their control. And
when they try to change *those*, management gets highly upset and kicks
the whole thing to the curb.
However, it is certainly possible to plan a strategy for exposing what
you are doing. Big Visible Walls (Information Radiators) are one key
part of that. Slipping in burndown charts with the normal information is
another.
But don't bother calling it Scrum. Or agile. Just call it getting stuff
done. And when you become highly productive, show them what you do. And
then come back and tell us all about it! ;)
--
Cory Foy
http://www.coryfoy.com
http://twitter.com/cory_foy
nela
To George:
"None of this sounds like stuff that's needed on an Agile project. "
The point is that the company has not accepted Scrum officially, and
let me run a pilot project with Scrum. So, I still have to do all the
stuff they expect from a PM, even though an Agile project does not
need it. Hm, am I doing things double here??
To Cory:
" From what you've told me, you are better off as the ScrumMaster -
but be cautious."
The more I look into this, the more I read in this group and generally
online, I think the SM would be my role. I am not afraid of losing
anything like authority, and I am perfectly aware that the higher
management will still blame me if something goes wrong. But - when I
succeed !! That will be sweet ! :-) Even if it is at a local level. It
is a department within a software company, the company is 500+ people,
and the department is cca 30-40 people. My team currently is 14 in
total, not all need to be on this particular project.
----
"Which means that when the pressure is applied, you will be expected
to resort to traditional Project Management techniques. "
That is true. Those guys up there won't change... yet.
----
"Now, that solution might be for them to ask you to do it. But
ultimately it is their responsibility for making sure it is done. This
is why it can be challenging to implement Scrum in organizations which
maintain a traditional PM mindset."
I can ask them to do it, or they can ask me to do it, but only within
the Scrum team we will agree that it is their responsibility. Only
between us. Anything going out to the rest of the company - the whole
thing is my responsibility. I don't mind, I see every problem at work
as a good challenge anyway. Even if I have to show them the errors of
their ways, and suggest process improvement. I have done that already,
while working on a international project. The company knows me
already: if someone will have the courage to do what has not been done
yet, it will be me. :-)
To Peter:
"> people then book their time on
> certain tasks,
This is no longer required at all. "
That may be so in Scrum-companies, but it is certainly required where
I am - even though it is western Europe, people clock-in and clock-out
of the building like in some old communist country factory ! :-) Each
hour of the day has to be booked later through the system - what
projects have you spent your time on. And the more detailed plan with
detailed task I make, the more detailed time the guys have to book.
Half an hour on this task, two hours on that task, one hour for this
project meeting etc etc. That will stay for some time to come. But I
just have to be very careful with my project time and PD estimate.
Then I will be ok.
To Cory:
"But don't bother calling it Scrum. Or agile. Just call it getting
stuff done."
That is exactly what I am going to do! And I am sure I will convince
all the non-believers.
Anyway, tonight I have gone to the scrumalliance website to the online
exam and passed the CSM.
You can find me - surname: Soldatov-Jones
End of January will be the turning point - as my boss goes for a
meeting with the Scrum trainer to see how Scrum could fit into our
organisation. I will be there too. It should be an interesting
meeting. The trainer is Peter Beck.
Bye for now, I will keep you updated!
Regards,
Nela.
George Dinwiddie
> Hi guys,
>
> To George:
> "None of this sounds like stuff that's needed on an Agile project. "
> The point is that the company has not accepted Scrum officially, and
> let me run a pilot project with Scrum. So, I still have to do all the
> stuff they expect from a PM, even though an Agile project does not
> need it. Hm, am I doing things double here??
Do they expect you to break the work down into tasks? Do they expect you
to assign tasks to the team members?
If you do these things, then how can the team self-organize? Where is
the agility?
nela
thanks for the comments,
> If you do these things, then how can the team self-organize? Where is
> the agility?
They expect me to break the tasks and give the tasks to the team...
but ... !
I was thinking to do it like this:
I have the planning phase, the execution phase and the closing phase.
Planning is the budget and estimates. The detailed tasks are only in
the execution phase.
What I am thinking of doing is generalising the tasks in the execution
phase, and not enter the subtasks at all.
For example, I will enter one task called "database creation" and in
it will be a multitude of tasks, which the team will manage. Another
task may be "Web gui". The team members involved in one of those tasks
will book on the particular task they have been working on, or on both
(half-half) if they work on both. I would not bother them to
necessarily be exact. The subtasks will be detailed by the team in the
sprint backlog I think... I haven't worked it out totally in my head
yet.
But I would allow the team to finish a task, however they think they
should finish the task. And plan the sprint tasks how they think is
achievable. (Conceivable-believable-achievable :-)
Something like that.
What do you think?
Nela.
Ron Jeffries
wrote:
> Something like that.
> What do you think?
I think the team is supposed to make up the tasks and sign up for
them. I think you should not be doing anything of the kind.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If you want to garden, you have to bend down and touch the soil.
Gardening is a practice, not an idea.
-- Thich Nhat Hanh
nela
I was thinking for some time about your post,and reading again, and I
am not sure now, even after reading a lot about Scrum in the last few
months. (Maybe not enough).
In a proper Scrum project, who creates the product backlog in the
first place? Product owner ?
As I said before "I will enter one task called "database creation" =
it is wrong. What it should be then is:
The PO will take a task from the product backlog, for example, the
task will be "database creation"
Then, during a Sprint the Team will agree on 25 subtasks needed to
fulfill this task, and the Team will assign the subtasks to
themselves. In that way, each "general" product backlog item is broken
down into subtasks during a sprint, and the Team decides what can be
delivered until next Sprint.
Did I understand right?
thx
Nela
cory...@gmail.com
What I think you are getting caught up on is vision versus execution.
What the Product Owner brings is a vision to the team of how the work they are doing delivers value to the customer. So a product owner would never say "database creation" but instead say "As a marketing rep I need to be able to report on the last 30 transactions where the amount was greater than $10k".
That said, what I think you are doing is guerrilla adoption. In that case, the team and the product owner should get together to figure out the plan of attack of whatever legacy process they are being forced to follow.
Cory
Sent from my Verizon Wireless BlackBerry
Ron Jeffries
wrote:
> I was thinking for some time about your post,and reading again, and I
> am not sure now, even after reading a lot about Scrum in the last few
> months. (Maybe not enough).
> In a proper Scrum project, who creates the product backlog in the
> first place? Product owner ?
Yes.
> As I said before "I will enter one task called "database creation" =
> it is wrong. What it should be then is:
> The PO will take a task from the product backlog, for example, the
> task will be "database creation"
Some people might allow that. I would not. "Database Creation" has
no business value and therefore is not a good backlog item.
A series of "stories" (backlog items) that might lead to a database
being created might be:
1. Customer enters his name and address and system prints
order pick and shipping label to that address.
2. Customer returns tomorrow. System remembers his address.
3. System can remember the addresses of a million customers for
as long as our company exists.
Note, however, that there are other ways to support these stories
than by creating a database. Creating a database is a technical
choice of one way to support the system's needs. It is a technical
decision made by the team.
> Then, during a Sprint the Team will agree on 25 subtasks needed to
> fulfill this task, and the Team will assign the subtasks to
> themselves. In that way, each "general" product backlog item is broken
> down into subtasks during a sprint, and the Team decides what can be
> delivered until next Sprint.
> Did I understand right?
In Scrum things the PO selects are called backlog items, not tasks.
The team is said to list "tasks" that add up to the desired backlog
item. In modern parlance, backlog items are often called "stories",
a term that, historically, is borrowed from Extreme Programming.
Breaking backlog items into tasks seems to be the current state of
"official" Scrum thinking. In the experience of those of us who
actually get involved in how teams write software, there are issues
with what you write above.
First, 25 tasks is almost certainly way too many. Five would be more
likely. With 25, integration will be hell and surely the story is
going to take a long time and is therefore much too large.
Second, there are two ways to split up stories. One is into what I
would call "technical tasks", like "set up new DB table", "add
fields to GUI", etc. Another way is to split the large story into
smaller items which are still like stories. My 1, 2, 3 example above
might be seen as having been split out as stories from a larger
story, perhaps
Up to a million people can enter their name and address into the
system and it will be used on picking lists and shipping labels
and will be remembered forever.
I hope that helps ...
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
A lot of preconceptions can be dismissed when you actually
try something out. -- Bruce Eckel
Vernon Stinebaker
On Dec 29, 2009, at 4:39 PM, nela wrote:
> Hi Ron,
> I was thinking for some time about your post,and reading again, and I
> am not sure now, even after reading a lot about Scrum in the last few
> months. (Maybe not enough).
> In a proper Scrum project, who creates the product backlog in the
> first place? Product owner ?
Yes, the Product Owner is responsible for owning and maintaining the product backlog.
> As I said before "I will enter one task called "database creation" =
> it is wrong.
Generally a good Product Backlog item should be a business valued item (user valued and user verifiable). Database creation might be a valuable task to put into the Sprint Backlog, but probably isn't that appropriate for the Product Backlog since it is an implementation level detail, and not something directly valued by the user or, directly, verifiable by the user).
> What it should be then is:
> The PO will take a task from the product backlog, for example, the
> task will be "database creation"
PO taking a task from the Product Backlog? The PO prioritizes the Product Backlog, the team commits to what they can perform in the upcoming Sprint.
> Then, during a Sprint
Usually before the Sprint, during Sprint Planning
> the Team will agree on 25 subtasks needed to
> fulfill this task, and the Team will assign the subtasks to
> themselves.
Or, more ideally, the team will pull the tasks as they complete a previous task, as opposed to "assigning subtasks to themselves" during the Sprint Planning meeting. This way workload is balanced even and efficiency is maximized.
> In that way, each "general" product backlog item is broken
> down into subtasks during a sprint, and the Team decides what can be
> delivered until next Sprint.
The team decides on what they will commit to during the Sprint Planning. They often decide to break Product Backlog items down into tasks (subtasks, as you've described them), and decide which task they will work on first. Then, as they complete one task they pull another task to work on to balance the workload and maximize efficiency.
> Did I understand right?
There still appear to be some gaps in your understanding. If you've not already taken a CSM course that would be a good place to start as this topic would likely be covered in some detail in the course. There are also so very good books available such as Mike Cohn's User Stories Applied and Agile Estimating and Planning that describe these processes (and the surrounding processes) in great detail.
-Vernon
George Dinwiddie
nela wrote:
> Hi George,
> thanks for the comments,
>
>> If you do these things, then how can the team self-organize? Where is
>> the agility?
> They expect me to break the tasks and give the tasks to the team...
> but ... !
Yes, it's difficult to be between a "traditional" organization and a
team trying to move to Agile. In my experience, those that excel in
this position are those who can effectively translate what the team is
doing into terms the organization can understand, without affecting what
the team is doing.
> I was thinking to do it like this:
> I have the planning phase, the execution phase and the closing phase.
> Planning is the budget and estimates. The detailed tasks are only in
> the execution phase.
> What I am thinking of doing is generalising the tasks in the execution
> phase, and not enter the subtasks at all.
> For example, I will enter one task called "database creation" and in
> it will be a multitude of tasks, which the team will manage. Another
> task may be "Web gui". The team members involved in one of those tasks
> will book on the particular task they have been working on, or on both
> (half-half) if they work on both. I would not bother them to
> necessarily be exact. The subtasks will be detailed by the team in the
> sprint backlog I think... I haven't worked it out totally in my head
> yet.
That's a common way of approaching the problem. The flaw in that
approach is that the tasks cannot be known well in advance, and there is
no way of determining when they're /really/ done.
I would suggest that where the plan calls for tasks, you enter the
features (or high-level stories), instead. This will look enough like
tasks for the organization, and will require less translation on your part.
(I also suggest having the team split these into smaller stories, rather
than subtasks. That's a different conversation, though.)
> But I would allow the team to finish a task, however they think they
> should finish the task. And plan the sprint tasks how they think is
> achievable. (Conceivable-believable-achievable :-)
Tell the business that you're not assigning particular tasks to
particular people, because you want them to adjust as needed to reduce
waste. "Waste" is such a wonderful word from the Lean lexicon, as no
business person can come out in favor of more waste.
> Something like that.
> What do you think?
I think it's a good beginning. Keep thinking how you can improve it.
Keep thinking about it forever, and improving forever.
nela
> There still appear to be some gaps in your understanding. If you've not already taken a CSM course ...
I have done it, as a matter of fact in mid December, just few weeks
ago, but it was in german :-( and my german is just starting to be
good enough to order food in restaurant or go to the shop! I did my
best, and a lot of reading about it in english. I have a lot of
questions still, because I still think that a 2 day course doesn't
cover half of the topics needed for a smooth transition.
I don't think many are going on a CSM two day course because they just
started a brand new SW company, never done anything yet, and decided
to start sw development straight away with scrum. I think everybody or
at least most of the people are doing some kind of transition from a
waterfall system. And that is the biggest issue - which is not covered
on the course at all. The suggestion was - let us talk about it in a
separate session :-)
I wonder if any company just drops completely the method they used
before, and from January 1st (figure of speech) - take on a new
method...
I am going to walk the dog now (having just come home from work), then
will be back to read more ... and answer more... ... and ask more :-)
bye
and thanks a lot !
Nela.
George Dinwiddie
nela wrote:
> The PO will take a task from the product backlog, for example, the
> task will be "database creation"
Do you understand the difference between tasks and user stories?
I've found that one of the fundamental keys to success is, rather than
break the work down into arbitrary "things that need to be done," break
it down into "functional pieces that can be seen to be working."
nela
Hi George
yes, I do now, and I realise I used a wrong example. Let me think of
my previous project, in insurance.
We needed an integrated system to sell insurance policies.
In this case if this was Scrum, I would say that one item in the
Product backlog would be "Motor third party insurance policy, required
data entry and storage, premium calculation and policy issue,
printout." The next item would be comprehensive insurance, next item
could be property insurance and so on.
Presuming all is defined from the client's side, we can all sit down
and do the Sprint planning.
The team commits the "Third party ins." as something they can deliver
in the first release.
Now, the first item is taken out of the product backlog and put into
sprint backlog.
Now - the team starts analysing what actually needs to be done - and
self-organises: you do this, I will do that, when you finish this I
can do that. And it will be ready for the next sprint. Even in
skeleton form.
(now I think of it, in that particular project Scrum would have done
wonders... ...)
:-)
Nela
nela
As Vernon said:
"Product backlog item - directly valued by the user or, directly
verifiable by the user..."
So in my insurance example = product backlog item would be "motor TP
insurance" because if that is delivered, the user can enter persons
details, vehicle details, calculate premium, create a policy, save it,
print it. So, the user can verify it by checking what is on the
printed policy, checking in the system if all the data is stored and
retrievable... And if all that is ok - the job is done.
One product backlog item delivered. Insurance staff can sell motor
third party policies.
They can't do comprehensive, or property, or liability. Yet.
Go to the next Sprint Planning meeting and see how many user stories
the team can plan for the next Sprint. Maybe two this time? (as they
have to be similar and integrated - for example: personal data saved
in the same way in the same place... )
As I said, I am just checking my understanding with you. I have a team
of experts here, what more could I wish for!
bye
Nela.
George Dinwiddie
It looks like you're on your way.
- George
> --
>
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>
>
>
--
nela
idea now of the whole process, roles, and my particular situation.
You have been more than a great help !
Regards,
Nela.