I like to pass along my thought process and habits to those I work with. (Which is good because, well, it's what I get paid to do.) For example, 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 Scrum Master 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.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.
Show me, and I may remember.
Involve me, and I will understand.
- Confucius, 450 B.C.
I look at the stories that haven't been estimated as well as the next iteration or two.The Scrum Master 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.
Can the team estimate the story?
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?
How does the next iteration look?
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?
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 to need?
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
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)?
I hope you find this useful.
photo credit: Tomasz Wiech