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.

  • 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 at 19:04
  • I'm being told by the engineers, they seem to be creating merge requests throughout the sprints – Breezecom Feb 10 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 at 23:24
  • What do you mean by "live"? Do they go live during a sprint? – nvoigt Feb 11 at 11:19
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

  • "Remember Halfway scrum is not scrum at all". You resumed the answer to OP on this phrase. +1! – Tiago Cardoso Feb 25 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.

  • 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 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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