Unrealistic deadlines can be highly stressful. One approach to dealing with them is to reflect the pain back.
Your management may not be feeling the pain the team is feeling in delivering against artificial and aggressive deadlines. Your challenge is to make sure they see the consequences of their actions.
Acceptance criteria are story specific requirements that must be met for the story to be completed. They are a technique for adding functional detail to user stories. Acceptance criteria are often added during backlog refinement or during the sprint planning meeting.
Some examples of acceptance criteria:
Sometimes a team finds themselves with requirements that require a lot of back-end development and a small amount of front-end work. If the team has specialist front-end and back-end developers then it may be tricky to balance the workload.
One approach I have seen work is to initially stub the back-end functionality before doing the detailed development work.
A Kanban board helps developers synchronise their work.
Scrum teams take user stories into sprints.
For many teams that is the end of the conversation. They do not need anything else to describe the work they are doing and the requirements they plan to do in the future.
For other teams, particularly those with a long product backlog, it may be beneficial to use other terms for requirements. Terms like 'epic' and 'theme'.
It is tempting to think of sprint retrospectives as a part of the reporting process. A chance to let people outside of your Scrum Team know what you are discussing and how you are improving.
There are dangers with this approach:
Software development has traditionally been done in projects.
Wikipedia describes a project as:
In contemporary business and science, a project is an individual or collaborative enterprise, possibly involving research or design, that is carefully planned, usually by a project team, to achieve a particular aim.
The first few steps in an agile transformation are critical to success. Lay a good foundation and what follows will be simplified.
So what is a good way to start an agile transformation?
The following are some common Scrum myths.
Isn't a higher velocity a sign of a more productive team?
The Scrum guide is very clear that velocity is purely about establishing the likely capacity of a team for future sprints. The actual value is irrelevant, it is the predictability that is important.
1. Mike Cohn - Mountain Goat Software
One of the founders of agile, Mike speaks with authority on a number of agile subjects. His focus is slightly more towards the product/project side with less focus on engineering practices.