2

First time doing this, seems to be working well.

I am currently the Product manager/Scrum master, I have a team of 2 developers and a QA tester.

Product is organised in the following way:

  • Weekly sprints.
  • After a sprint ends. A sprint retrospective happens with the main stakeholder showing what has been achieved from the sprint the week before, stakeholder and I have a brainstorming session on how to improve the product. Backlog is groomed.
  • Sprint planning session with the development team then takes place.
  • Based on the stakeholder needs following the last sprint, sprint plan for the new sprint comprises of backlog tasks prioritised according to stakeholder needs. The new items are generally high priority tasks. These tasks are estimated based on story points which are given by the development team.
  • I then use a burn down chart to track progress of the team during the sprint. I use this as a topic of discussion during daily stand ups and deal with impediments.

If the stakeholder intervenes during a sprint, I step in and tell him that he should wait until the next sprint before asking the team to do tasks outside of the sprint.

Cycle repeats itself.

Improve this question

1 Answer 1

Reset to default
1

You are doing a lot right, but there are a few areas that are not following the Scrum Guide.

There are typically two Scrum ceremonies at the end of each sprint: the sprint review and the retrospective. It sounds like you are combining these in to one meeting.

In the sprint review the Scrum Team meets with interested stakeholders and shows what has been done in the sprint. During the sprint review the stakeholders typically provide feedback, which the Product Owner may decide to use to adjust the product backlog.

The other meeting is the sprint retrospective. This is only for the Scrum Team and does not include stakeholders or others from outside the team. During the retrospective the team inspects how the sprint went and thinks of ways to adapt their approach in order to improve.

The reason the stakeholders do not attend the retrospective is that the Scrum Team may feel nervous about discussing some topics in front of them. To ensure that the retrospective is an open and productive discussion we limit who can attend.

The final area where you differ from the Scrum Guide is in the role of Product Owner. In Scrum the Product Owner is the product champion and they are responsible for managing the product backlog. It sounds like in your setup the Product Owner role has been split across you and the stakeholder. It may be worth considering having the stakeholder become the Product Owner if they are the person who is making decisions about the product.

I would encourage you to carefully read the Scrum Guide and if possible look to get some Scrum Master training. This will help you to understand how Scrum works.

Improve this answer
7
  • Ok point taken for point one, point two - Product Owner - there is some confusion about this, since I am helping the MD (main stakeholder) with ideas, and grooming the backlog. Often my ideas are taken on board, however officially it is his idea, and gives approval for any ideas that go into the backlog....am I correct in saying that I am the product manager?
    – bobo2000
    Commented Apr 20, 2016 at 11:26
  • There is no role called 'Product Manager' in Scrum, only the 'Product Owner'. One of the strengths of Scrum is that there is only one Product Owner. They are the only person who can make decisions on the backlog (what goes in, what comes out and the priority order). There are two solutions to your situation: firstly get the MD to be the Product Owner or secondly, get the MD to give you the authority to make decisions about the product. You will still take the MD's feedback into consideration, but as Product Owner you will be the one that has the final say on the backlog.
    – Barnaby Golden
    Commented Apr 20, 2016 at 11:30
  • ah that makes sense -a bit confusing since there are job titles out there with 'Digital Product Manager' and 'Digital Product Owner?' (what's the difference)...Well the way it is working currently, is that the stakeholder and I come to an agreement on what goes into the backlog. So I suppose I am the Product Owner since I am making decisions about the product based on his feedback?
    – bobo2000
    Commented Apr 20, 2016 at 11:34
  • If it works for you then that is fine. There is a danger of having what is called a 'proxy Product Owner'. This is a person with no authority in the Product Owner role who has to continually ask a stakeholder permission to make changes. The danger with this is that the team will have to wait while the proxy Product Owner asks the question. It is much more efficient if the team can know that there is just one person guiding the backlog, so they always know who to talk to. Take a look at: scrumalliance.org/community/articles/2010/april/…
    – Barnaby Golden
    Commented Apr 20, 2016 at 11:44
  • 1
    Ah right, so I am effectively that from the sounds of it. Only I am doing that with one Stakeholder (the MD)
    – bobo2000
    Commented Apr 20, 2016 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.