Advice on refinement and planning
I'm currently working with a team and an SM and we do refinement on a weekly basis, taking a 3 Amigos approach using BDD style discussions and scenarios. I'm having a problem with some suggestions a manager is giving.
One the managers of the developers has suggested we spend more time on technical investigation of approaches in advance of sprint planning - I consider these technical spikes. That's fine as the team is mostly junior and the product is quite complex technically - our first sprint planning the developers seemed not to understand how they would go about the plan.
He has suggested the developer doing plans out the technical tasks before we get to both refinement and Distil. In other words, he's suggesting that having a story tasked out should be part of its Definition of Ready. To me, this is a bad idea - surely its dangerous to conflate a DoR with the technical How being fully known?
I would think we want to leave it as open as possible for the requirements to emerge in refinement through story telling. I can understand that a spike may affect the requirements in terms of feasibility - that's fine. But coming into sprint planning with a story fully tasked out seems counter to what sprint planning is about, which is taking a whole team approach to tasking out.
What do you think?
In my experience, teams that complete (even tentatively) a task list for a PBI gain some insight into the size and complexity of the item.
Yes, your observation around the "what" turning into the "how" is accurate, but there is some benefit to the estimation and planning process with that type of refinement effort.
I would question though the manager's suggestion that a single Development Team member be responsible for creating the tasks. This should be a team-based effort, and not a responsibility allocated to a single individual.
But coming into sprint planning with a story fully tasked out seems counter to what sprint planning is about, which is taking a whole team approach to tasking out.
How much tasking-out would be needed for the Development Team to be able to estimate a PBI?
Bear in mind also that certain technical criteria might need to be asserted in the Definition of Done. Tasks may subsequently be identified for them in Sprint Planning.
I generally suggest doing estimating before tasking. If there is unknowns we do a spike to help estimate.
Why is one of the managers suggesting that a self organized team do this in the first place? Is there actually a problem to be solved? If so why not bring it to the Scrum Team?
That's a good question, Chris - another problem which needs to be resolved. Manager is too involved.
In terms of a story being Ready for a sprint and estimated, what do you think is the appropriate level of technical knowledge of the story needed? It feels like if we were to do this investigative tasking for each and every story in advance, it would surely lead to a lot of context switching vs current sprint items. There has to be a stage where you say "we know enough and we'll discover some stuff during the sprint" surely?
>> In terms of a story being Ready for a sprint and estimated, what do you think is the appropriate level of technical knowledge of the story needed?
I have seen teams consume their Sprints with Spikes to get better estimates, which is an XP term by the way. Honestly I feel like using Spikes is falling back on the old predictive mindset, and is wasteful. Use them sparingly, if you use them at all. Do Spikes deliver any end value for the customer for the current Sprint? Probably not. Estimation does not have to be perfect, as they Development Team will learn more daily (Inspect and Adapt).
The technical implementation can be saved for Sprint Planning, when the Development Team determines "The How" portion of their Sprint Backlog. I see many Development Teams get wrapped around the axle when it comes to estimation. Is your Development Team using relative estimates? I would argue very little technical details are needed for relative estimation, as they are comparing one Product Backlog item to another. In other words, is this PBI relatively bigger or smaller than this other PBI. What may help you is to teach the team about anchors to be used for comparison. An affinity grouping exercise may also help.
>> There has to be a stage where you say "we know enough and we'll discover some stuff during the sprint" surely?
That's the right spirit, and the reason why we use empiricism in the first place. Every day in your daily Scrum the Development Team will inspect the Sprint Goal and adapt the Sprint Backlog, and if they over or underestimated a Product Backlog item, that's okay. They just have to talk to the Product Owner, and keep the Sprint Goal in mind - it provides flexibility.