Sprint Planning

The following from the scrum guide springs to mind: 

Topic Three: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.



The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

The SG in no way states that it is the job of the SM to create the plan, but it does clearly state that it is the Developers that plan the work.

If I were in your place, I would tell them that I am not a project manager and that the way they organize their work is up to them. If they choose to produce this plan, they can maintain it as well.  Then I would watch overtime to see what kind of problems, if any, they have with maintaining or achieving the plan as they create it.  Use that information to fuel conversations about the usefulness or maintenance of the plan during Sprint Retrospectives.  

Remember, this statement from the Scrum Guide's section on Sprint Planning (emphasis by me)

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

If they create it, maintain it, and find it useful who's to say it is the wrong thing to do?  However, be sure that they still use the Daily Scrum for its intended use of inspecting and adapting the days work based upon what they have learned and the progress towards achieving the Sprint Goal.  Don't let them turn it into a quick status meeting. 

Thank you Scott and Daniel. Great advice. I think the real problem here is in helping my team to become self-managed, as opposed to being told what to do and when.  I have managed to push back on the plan on a page today - as to be honest, the team don’t want the admin overhead, but quite happy for someone else (ie me) to do this for them (which I will not).  

Although my initial question, came under the heading of sprint planning, I think the real issue is something else - I would really love advice re empowering teams to self manage.....when they just want direction...

Many thanks and grateful for advice

Gill

I totally agree with Daniel here.

The Sprint Backlog is the plan for the Sprint and is entirely owned and managed by the Developers. Unless you are a Developer, you shouldn't be doing anything with the Sprint Backlog regardless of the form. As a Scrum Master, I'd be available to help the Developers learn about good and effective techniques for executing Sprint Planning and creating and maintaining their Sprint Backlog.

In this particular case, I'd also be opposed to the idea. However, if the team wanted to try it as an experiment, I wouldn't stop them. Depending on the context, I'd either not say anything unless they explicitly asked or I'd use it as a teaching opportunity to explain why the detailed and rigid planning at Sprint Planning is a risky activity. In the end, though, it would be up to the Developers to decide if they want to go forward with their experiment or not.

Yikes, the death of empiricism one sprint at a time.  Well, maybe not that bad.

I'd ask the folks what would happen if this daily plan changes?  Rework?  What about whole team swarming and sharing?  

You can always say "hey team let's try it", but I want to see a plan for how to change the plan.   If you see people picking things coming up in the product backlog and not helping each other, that's something to note in the retrospective.

Ultimately, asking yourself why they want to do this may lead to a better solution to suggest.

Saying the scrum guide alludes to not doing this may invoke the response "so what".  Saying this is actually going to cause you (the team) more work is probably a better approach.

I think the real issue is something else - I would really love advice re empowering teams to self manage.....when they just want direction...

Scrum is used for solving complex problems, where more is unknown about the solution than is known. The creativity of a team must be brought to bear, since any plan can never be more than a forecast of the work. The team must continually inspect and adapt it. No one person can prescribe the work that will be needed.

Is it actually a complex challenge being faced by the team?