Mainframe Blog

Avoid Agile Sprint Planning Panic

2 minute read
Zyad Alyashae, Mark Schettenhelm

Overview: Panic is never good, but proper preparation can keep it from seeping into your Agile sprint planning meetings. Use these 7 tips to help plan properly and avoid panic.


At times, Agile sprint planning meetings can cause panic, and that’s never a good thing. One example is when items aren’t defined clearly enough—it becomes difficult to allot stories when they aren’t clearly understood. Agile development is by nature fast-paced, but if planning is done right you shouldn’t be in a situation that leads to panic. Here are 7 tips you should consider to avoid panic at your next planning meeting.

1. Schedule a mini-refinement. If research will be completed right at the planning meeting, schedule a mini-refinement meeting a day or two before the planning meeting to discuss dependent stories based on current knowledge. If things substantially change before the planning meeting, you can adjust then.

2. Don’t over-refine. Know that you won’t have every detail worked out. Sometimes you don’t know until you are deep into it – there can and will be surprises. Stories do need to be well –refined, but realize that they will never be totally refined and not all questions will be answered. Be efficient and refine just enough to commit to the work.

3. Refine with the likely path. “Pencil in” the way you currently feel it will be and adjust if things change. Granularly refine. That is, refine all the stories ahead of time to the best of the team’s ability and continue refining the more you learn about the dependent stories.

4. Refine what you know. Consider breaking stories into subtasks and refine the ones you know, leaving the questionable ones to be filled in later.

5. State the things that are unclear. Talk about the “elephant in the room;” point out the items that are unclear and match them with the stories that will provide the answers. That way, when it gets down to the mini-refinement, you can refer to these stories.

6. Research and code. Sometimes it’s better to apply a hybrid approach. Having them together means that you avoid the lag that’s associated with starting another story. If you do this you might want to schedule a quick review before turning to coding.

7. Establish checkpoints. If certain criteria should be met before you go to the planning meeting, then it’s a good idea to schedule checkpoints to keep the criteria aligned. Scheduling a checkpoint during sprints where a story may block future work allows for quick exchange of thoughts which prepares the development team and reduces panic during the next planning meeting.

You do need to thoroughly refine but sometimes schedules won’t allow you to refine at a set interval. We recommend that you take a step back and understand that the process is iterative, and each cycle produces its own piece of the puzzle. You can’t pause progress to meet the ceremonies, but you can work toward a balance. Adopting these practices will help you to produce more, with less refinement panic.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing

Business, Faster than Humanly Possible

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.
Learn more about BMC ›

About the author

Zyad Alyashae

Zyad Alyashae, Product Developer for BMC AMI DevX Code Pipeline, has experience working within various sectors in the tech industry, including mainframe, marketing, telecommunications and automotive. He has an eye for writing code that is scalable and maintainable for the future.

About the author

Mark Schettenhelm

Mark is a DevOps Evangelist and Lead Product Manager at BMC who has experience working with developers around the world in Source Control Management, Testing, DevOps and Application Portfolio Analysis. He is a frequent conference speaker, webinar presenter, blogger, and columnist, often explaining the benefits of bringing Agile and DevOps to mainframe development and encouraging development teams to adopt new methodologies and continuously improve.

His writing has appeared in Enterprise Executive and Enterprise Tech Journal and he is a frequent contributor to and SHARE Tech Watch. Mark is currently the Lead Product Manager for BMC products in Source Control Management, Deploy, Code and Fault Analysis.