Always Looking Ahead
I’m always looking ahead to the next planning or the next estimating meeting. I teach this behavior to my clients whenever I’m coaching a new ScrumMaster or Product Owner. I start off by involving them in what I’m doing, showing what needs to be done and by explaining my thinking. The teaching is very experiential, yet incomplete in a way. If I explained everything in my head, everything I was looking out for, I’d be doing too much telling and not enough involving.
Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
– Confucius, 450 B.C.
Yet there comes a point where I’m about to push them out of the nest and let them fly solo when I become more explicit about teaching my thinking. This leads me to throw down a list of things to remember, to refer to later, always tailored to the local context. Experience tells you what to look for and this is somewhat different in each situation so please don’t expect this to be an effective checklist for your organization. But in general I keep the following questions in mind.
I look at the stories that haven’t been estimated:
- Can the team estimate the story?
- Is the story too big?
I look at the next 3 sprints worth of stories:
- Can the team plan the story?
- Are the descriptions good?
- Are the acceptance criteria sufficient?
- Is the story too big?
- Does the team need to do a spike first?
I look at the next sprint:
- Too many points? Not enough?
- Are there un-estimated stories in there?
- Are the stories prioritized?
- Have we given the team some advance notice as to what we have in mind for the next Sprint?
- If we have specialization or multiple teams for one backlog, should we think about which team should take each story? Does the next iteration look balanced between the teams/specializations?
I look forward to the next deployment and next release cycle:
- How does our release burn-down look?
- How does the release backlog look?
- Will we have stories ready and estimated in advance of the start of the next release?
- How much lead time do we need?
I look for overlooked items in the backlog:
- If I’m using an online backlog management tool, am I overlooking some stories not in my standard filter because they haven’t yet been slotted into an iteration or assigned to a team?
- When using an online tool for backlog management, I set up views or queries to help us answer those questions: (That’s provided naturally by some tools, can be set up with a little work in other tools, and is downright impossible in others.)
- No Estimate
- No Team
- No Sprint
- This Sprint
- Next Sprint
- Release Plan
I look at the calendar:
- Looking more than one iteration ahead, are there holidays coming up that will fall on a regularly scheduled estimating or planning day (or a pre-planning/pre-estimating day)?
The ScrumMaster can help keep an eye on things and point out what is lacking, but the bulk of the decision making of course belongs to the product owner.
I hope you find this useful. What else should I add to my list?
Comments (7)
Derek Huether
Andrew, I love the list. At every step of the refinement process, I ask the team: Is this story dependent on anything? When using an online backlog management tool, I use a query that lists “stories with dependencies”, as I’m continually having the teams seek out and break dependencies. If there are any business, organizational, or technical dependencies, I ask the team to consider rewriting the story to eliminate them.
Hard to believe I didn’t include dependencies in my list. Not sure how I overlooked that one! Thanks Derek.
John Borys
I have some questions about your looking ahead to the next sprint. If the PO determines what the priorities are and those priorities can change at any time, why/how would you know these things?
“•Too many points? Not enough?
•Are there un-estimated stories in there?
•Are the stories prioritized?
•Have we given the team some advance notice as to what we have in mind for the next Sprint?”
Are you planning your sprints in advance? If so, why would you do that? I understand that backlog refinement meetings occur and you can talk about what you think you might do in the next sprint while sizing those stories. But these things listed can only be determined if you have actually finished your Sprint Planning. This should take place after the completed Sprint and before the start of the next one and the team should be involved. This smells like project management to me.
John, you and I likely have different contexts to consider. Thanks for challenging me on this. I need to make some clarifications:
If I have a large agile team that has dependencies, is part of a larger program, where the organization is making commitments some months out, where there are multiple stakeholders spread far and wide, where the system is not simple, where the subject matter is complicated, then there is often some amount of lead-time required (days or weeks) to make some user stories ready. In such a context, a single PO often doesn’t operate in isolation and can’t make dramatic priority changes at any time. That’s why I care (given my context) about always having 3 sprints of ready backlog at all times. If I’m bringing a dozen people into a sprint planning meeting, I don’t want to risk spending many minutes in that session talking about a story that we ultimately decide to toss out because it isn’t ready and can’t be made ready during this sprint. Project management in such a context isn’t a dirty word. Nor is it anti-agile.
Now let me address this point you made: “But these things listed can only be determined if you have actually finished your Sprint Planning.” If I know my team’s velocity and have a prioritized backlog, I can look at the top of the backlog to see if I have 2 or 3 sprints worth of estimated stories. Sometimes that’s all I need to know. I’m not fully planning sprints in advance — I’m not doing “Sprint Planning” with the whole team in advance — I’m not breaking stories into tasks in advance. I’m prepping. I’m making sure that when we do have planning it will go off without a hitch.
Does that help?
John Borys
The context helps, yes. The other things can be handled during backlog refinement meetings to prep the backlog prior to a Sprint Planning meeting. I think using Story Mapping or something similar to keep the whole thing together would probably be something to consider on a project that large. But your comments have me thinking about something else that I struggle with in trying to coach a large Enterprise through a transformation. At least that I struggle reconciling with the whole user story concept: “Dependencies”. We are often been told to use I.N.V.E.S.T. to create our stories, but how can stories be independent on large projects that have other teams building out services? And, if you are splitting things up that way (by components) the whole project tends to get split up along architectural boundaries. This means somewhere down the road, we have to integrate all these pieces. This, IMHO, is as Waterfall as it gets. So in these large projects you describe, and that I am working in now, how do we keep stories independent? If we can’t, how do we deliver an MVP without facing all the old issues associated with component based construction and delivery? (I know this is going off on a tangent, but giving the context you provided, I am hoping it is okay to extend the conversation in this direction.)
Change your organization and your architecture to eliminate dependencies. But that’s hard and takes a long time, right? So in the mean-time, dependencies are a fact of life for many organizations. Therefore, never inject dependencies on lower level teams. Higher level teams (i.e. like feature teams) must always accept (work with) the capabilities provided by the existing services. Don’t include things in your release plan that depend on a service team making changes in the same release time-frame. Do work with the service team PO to include things you want on their roadmap and work to get things into their release plan, but don’t make your plan dependent on theirs. Perhaps these 2 blog posts might help?
https://www.leadingagile.com/2011/10/dependencies-break-agile/
https://www.leadingagile.com/2013/07/use-feature-teams-component-teams/
Let’s continue the discussion either on one of those posts, this post, or elsewhere. Thanks again for engaging on this.
The other thing I should have mentioned is that if you can’t do eliminate or defer dependencies, then have an org policy that every team must resolve any dependencies on it at the start of each release before it works on any of its own stuff. Dependency resolution is top priority across the enterprise. That way, all work can be dependency free after the first sprint or two. Plan the release to visualize and front load dependency resolution.