In my work as a project manager I have come across many different approaches and best practices when it comes to how to run a project effeciently. I have never really relied on a single approach but have adapted what I feel is the best parts from each.
Below I have written some short pointers of what I like to focus on in regards of scope, deliveries and sprints.
Delivery scope
Once the total amount of work that will be considered part of the delivery is agreed upon with the client, this is then formalized as “scope”. The work is broken down into a set of user stories (more about this here). These user stories are added to the project backlog.
Out of scope
Once the delivery scope is agreed on its important to quickly flag any new additions or changes thats outside the agreed scope. This will have an effect on time and cost, most of the time it will add both. The client is able to then remove items from the backlog and replace these with the new items, to maintain the cost/time as originally planned. Removed items is then moved to the wishlist (out of scope) for later discussion.
Refinement
Once user stories are created it is important to do refinements of these, this usually involves the client, project manager and the developer(s). The purpose of the refinement is to make sure everyone has the same understanding of the task. This saves alot of time spent on questions and clearifications later. It will also ensure that the developer understands the clients needs getting the information directly from the source. It is also important to go through the acceptance criteria of each task during the refinement.
If the delivery is a bigger project its usually good to do the refinements with the developers on each sprint seperately, this to make sure the focus is on the sprint at hand.
In cases where client developer contact isnt possible the PM can do the refinements in two steps, first with client when US is created, later with devs when sprint starts.
Userstory not complete
If the user story is missing key information, documentation, acceptance criteria or other things critical for the delivery of the story it will be considered not refinable. In this case its not a candicate to be added to a sprint and should remain in the backlog until issue is corrected. Other stories which is complete could then take its place in the sprint.
Sprint planning
Each sprint is defined taking user stories from the backlog and adding them into the sprint. What parts of the delivery to focus on first varies depending on the delivery. Generally its recommended to start with the more heavy parts of the delivery, integrations or other backend tasks. The reason for this is that this is where unforseen complexity and impediments usually occur due to being dependant on 3d party APIs and providers.
If the resources are available its usually good to show progress in the design/front end in parallell with working with the core and back end features. The reasoning for this is that front end is alot easier to present to non technical clients. This way the client will see progress visually during sprints which mainly focus on integration and business logic.
On bigger projects/deliveries, its good to be ahead with the sprints, meaning that the client and PM is working on user stories for sprint 2 or 3 when development start work on 1. This will create a buffer and ensure that developers allways will have tasks ready.
Task breakdown and estimations
Once a sprint is set and userstories are refined the developers break down the user stories into tasks, each task is estimated. The total estimation of all tasks will give the total estimation on the sprint. Depending on the developers available during the sprint some user stories might be moved back to the backlog (or moved to next planned sprint) if the total estimation turns out to be difficult to deliver within 3 weeks.
Sprint demo/retrospective
At the end of each sprint a demo is scheduled, this is usually an internal technical demo where developers do a demo (if possible) of the work done. Any issues or feedback is also discussed. The PM then brings this information and demo to the client in a seperate meeting.