Project dependencies are classified at planning as finish-to-start, external, mandatory. The type never changes. The blocker’s age does, and that is what moves the committed date. Read it in days.
A written sprint capacity record turns ‘why did we commit to that?’ into a two-minute answer. Five items to capture each sprint, with a worked example.
What should a Scrum team do with unfinished work at the end of a sprint? Return it to the backlog, re-check the sprint goal, and plan the next sprint on real capacity.
How often should you update a release plan? Re-forecast every sprint, review scope at milestones, and re-baseline only when the goal changes.
How long should sprint planning take? Up to 8 hours for a one-month sprint, usually less for shorter sprints. Here is how to keep it inside the timebox.
A change request prices scope one form at a time, against a baseline that already moved, and much scope never files one. Price every change against the committed date instead, in days.
A project timeline shows the plan the team voted on. After the vote, scope, dependencies and capacity move. Keep the committed date live, in days.
A RAG status reads in a second, but nobody wrote down what amber means. Define each color in days against the committed date and the confidence the team voted at, and let it change when the data does.
Fixed go-live date, shrinking team? Compare required pace to real sprint capacity early, then decide on scope, staffing, or schedule with a clear record.
How to total each person’s program commitments against available sprint hours, rebalance anything over 100%, and record the decision before you commit.



