The daily scrum is the event where the development team inspects and adapts their work plan in order to make the most progress possible towards their sprint goal each day. It is one of the most misunderstood events in the scrum framework, and often implemented ineffectively. By understanding the purpose of the event, your team can realize much more value from their daily scrum.
Often, the first thing a person learns about scrum is the traditional way to run a daily scrum. They learn the three magic questions: What tasks did I get done yesterday? What tasks will I do today? What impediments am I aware of?
What people often don’t learn is why the team holds a daily scrum. If team members don’t understand the purpose, it’s very easy for the daily scrum to devolve into a meaningless status meeting, where each team member walks away wondering why they just wasted 15 minutes of their day.
Read the full article…
I encounter scrum teams changing, or worse, creating, story estimates during their 
Sprint planning is the cleverly named event where the scrum team creates their plan for the sprint. The outputs from sprint planning are: the sprint goal, the forecast of which product backlog items will be delivered, and the team’s work plan.
A client who is basing their scrum adoption on the 
To prioritize items in a scrum team’s product backlog, the product owner needs an estimate of both value and cost for each item. This way, they can identify which items have high 
A scrum team works from a prioritized list called the product backlog. Product backlog items are often called 
Scrum strikes a useful balance between flexibility and focus. In sprint planning, the product owner presents the most important objectives to the development team. The development team commits to as many of those as they believe they can deliver in the sprint. Once sprint planning is over, the business doesn’t change their mind about what they want. The development team is able to focus on delivering the product backlog items to which they committed. At the beginning of the next sprint, the business has another opportunity to change direction in any way they need to.
I recently facilitated a software development group’s transition from component scrum teams to feature scrum teams. The new structure reduces cross-team dependencies, which had been causing significant delays in shipping new features. Over the course of a day, we dissolved the existing component teams, refined a shared product backlog, created a shared definition of done, self-organized into new teams, and held