Many agile and scrum teams start with basic practices to enable self-organizing teams to better deliver on business priorities. Practices include committing to what teams can get done in a sprint, holding daily standups to manage work in progress, hosting demos for stakeholders to showcase completed work, and organizing retrospectives to discuss process improvements.
Using these fundamental practices, small agile teams can demonstrate business value by delivering incremental improvements and enabling stakeholders to weigh in on new priorities.
As organizations and teams mature their agile practices they are often faced with new questions. Leaders might ask, “Can you tell me when the feature we prioritized will be done,” or “Can you share with me a list of features that are likely to be done over the next few months?” A product owner might ask, “How expensive and complex is this enhancement,” and the operations team might want to know, “Can you squeeze in these defect fixes in the next sprint?”
Teams that dedicate themselves to process improvement often have related productivity and quality questions around their agile process. Many agile tools measure team velocity, or how much teams can get done in a sprint, and teams will want to define, measure, stabilize, and ideally increase their velocity. More advanced teams often want to look at their overall performance across many sprints: Are they delivering higher quality when they work on lots of small stories, or just a few big ones? What’s the impact if a team member is out on leave for an extended period, or, what more can they take on if new people are added to the team?
