1

Hi looking for some ideas....

One of my scrum teams is performing and releasing, we have regular deployments but the planning and board does not reflect the work they have done.

I'm not sure what this means, My first assumption is that the planning is not being done correctly.

The second issue with the same team is that they can get a certain amount of work done but find themselves unable to deliver the second batch of work in a 2 weeks sprint. So you end up with sprints where work has been pushed live and some tasks which are half finished. This is leading this is making the team think they should stop using sprint cycles (which is fine, if that will fix the issue).

Please share your thoughts it will be very helpful.

4
  • How do you know you're delivering if the board is not the source of delivered work? The team might be either tracking what's being delivered somewhere else (mails - God forgive us - for instance?) or you assume team is delivering but you're not sure about the content of the delivery. Besides, I'd suggest to focus on a single question, clarify it, and then raise another question. You'll harvest better answers doing so.
    – Tiago Cardoso
    Feb 10, 2019 at 19:04
  • I'm being told by the engineers, they seem to be creating merge requests throughout the sprints
    – Breezecom
    Feb 10, 2019 at 21:51
  • 1
    From a merge to a release there's a considerable amount of steps. Do you know which items are being delivered?
    – Tiago Cardoso
    Feb 10, 2019 at 23:24
  • What do you mean by "live"? Do they go live during a sprint?
    – nvoigt
    Feb 11, 2019 at 11:19

2 Answers 2

2

One of my scrum teams is performing and releasing, we have regular deployments but the planning and board does not reflect the work they have done.

How is this transparent? Transparency helps organizations to anticipate and eliminate undesired surprises and problems, and Scrum makes the teams' work visible and even allows it to be demonstrated at the end of each sprint.

I'm not sure what this means, My first assumption is that the planning is not being done correctly

I think if you plan a sprint the developers should add tasks to a story this will ensure that transparency is adhere to and this will also ensure that what is planned and what is done (on the board) matches.

So you end up with sprints where work has been pushed live and some tasks which are half finished

Stories can be carried over to next sprints but you should plan and try to meet the sprint goal.

This is leading this is making the team think they should stop using sprint cycles (which is fine, if that will fix the issue)

This is not the issue, You should have a retrospective at the end of the sprint to find the issues in the sprint.

I think you should go back to the drawing board and speak to the team about the concerns.

Remember Halfway scrum is not scrum at all

1
  • "Remember Halfway scrum is not scrum at all". You resumed the answer to OP on this phrase. +1!
    – Tiago Cardoso
    Feb 25, 2019 at 9:05
0

The scrum team will work on sprints.The team commits to Backlogs.And the metrics etc will be shown against the committed backlogs. But as per what you have said it boards are not reflecting what work has been done,then actually what basis the work is happening Is it that they just pick any workitems as it comes? Then looks Kanban is the way to go. Where you can track the team on their throughput.

1
  • I know its late response, and I agree with this answer. I've since changed Scrum Masters on that team and they seem to be doing much better.
    – Breezecom
    Jun 8, 2019 at 17:33

Your Answer

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

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