The analysis and design may take long, normally more than a day even for a 2-week sprint.

If I do them during sprint planning, then the planning will take too long, which normally should not be more than 8 hours.

If I do them before the planning, then it means I do them at last Sprint. This doesn’t sound scrum, right?

If I do them after the planning, then after I do them, work division and estimation may be different big time. As a result,the schedule changes a lot and the original Sprint plan may be kind of useless. I guess this is not a good way to manage expectations from the Product owner and the organzation, right?

2 Answers 2


Are your Product Backlog items "Ready" for Sprint Planning?

Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.

Sprint Planning is for just enough design.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work planned for the first days of the Sprint by the Development Team.

Analysis can best be achieved when done continuously.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

To answer your first question, within the Scrum framework it is expected that analysis occurs for items to be done in the future. In accordance with the Manifesto for Agile Software Development's values and principles, you shouldn't be creating a long term timeline with highly detailed specifications that cannot be easily changed.

Another concern, based on your post, is whether or not your Product Backlog items are scoped small enough. Are the items so large that a lot of design needs to be completed? That may be an indicator that refinement should include slicing items into smaller pieces that can be "Ready" for a Sprint. Toward your second question, this will help strengthen the Scrum Team and business relationship through more consistency; remember that the Sprint Backlog is a forecast and not a promise.

Stick with the authoritative:

http://scrumguides.org/ http://agilemanifesto.org/ https://www.scrum.org/


The idea is to be able to comfortably estimate for work items in sprint planning. How you get to that point is up to your team.

What a lot of teams will do is have backlog refinement sessions. These will be just long enough and frequent enough to ensure that when they get into sprint planning they have enough stories that are ready to be estimated to fill the next sprint.

The important part here is that you do just enough analysis and design to estimate. All the rest of the analysis and design work will take place in the sprint as a part of completing the work item.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.