When teams first start agile development, little has changed, other than perhaps more meetings on the schedule. They may still operate separately or limit their interactions with customers. You might see the work break down into waterfall kind of tasks, then design user stories, then build stories, then test stories. Therefore, the “Agile Teams” are agile in form when they just walk around without understanding or accepting agile principles and values. Teams become agile when they think and act in line with agile values and principles.
Continue readingCategory: Scrum
Definition of Ready in Scrum
The Definition of Ready is a set of agreements that lets everyone know when something is ready to begin, e.g., when a user story is ready to be taken into a sprint, or when all necessary conditions are right for a team to start a sprint. An appropriate definition of ready will substantially improve the Scrum team’s chance of successfully meeting its sprint goal.
Continue readingTransparency in Scrum
Transparency is the first important aspect of the Scrum process and must be visible to those responsible for the outcome. Transparency requires that these aspects be defined in their daily activities and artifacts so that teams can share a common understanding of what they see.
Continue readingWhat is Self Management Approach?
A self-managed team is a group of employees who are responsible for all or most aspects of producing a product or service. The self-managed team is the basic unit of the new horizontal organization. Self-managed teams are an outgrowth of the earlier team approach.
Continue readingWhat is a Sprint in Scrum?
Sprint is one timeboxed iteration of a continuous development cycle. Within a Sprint, planned amount of work has to be completed by the team and made ready for review. Scrum projects are broken down into small and consistent time intervals referred to as sprints. They can be as short as a few days and generally are no longer than 3–4 weeks.
Continue readingCross-functional vs Self-organizing vs Feature vs Component Teams in Agile
“A Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team” — Scrum Guide. In contrast to the component team approach, a cross-functional teams are groups consisting of people from different functional areas of the company. — it should be formed not only with technical specialists (Back-end, Front-end developers, QA engineers, etc.) but also consists of members like Business Analysts, Marketing and UX specialists or anyone else taking an active part in the project.
Continue readingScrum Guide Change: Self-Organizing vs Self Management Team
Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
Continue readingWriting Good User Stories
User stories are part of the agile approach and help shift the focus from writing requirements to discussing them. All agile user stories include one or two written sentences and, more importantly, a series of conversations about the desired functionality.
Continue readingThe 20 most frequently mentioned rules and guidelines in Scrum
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them as shown in the Figure below:
Continue readingAgile Estimation: Relative estimates vs Absolute estimates
Whether a team is developing a product or a project, we need to answer the question “When will we be able to finish it?” , or how far we will be able to go at a certain point in time, so as with traditional development models, we need to estimate the workload before we start the project. Agile estimation is the process of estimating the effort required to complete a priority task in the product backlog. This effort is usually measured in terms of the time required to complete that task, which in turn leads to accurate sprint planning.
Continue reading