Here at Apiumtech we confine work to a regular and repeatable work cycle known as a sprint or iteration. Scrum sprints used to be 30 days long, but here, we do shorter sprints. In fact, we do it in two-weeks.
Working within the boundaries of an accelerated timeframe
During each sprint, our teams creates a shippable product, no matter how basic that product is. Working within the boundaries of such an accelerated timeframe, the team is only able to build the most essential functionalities.
Placing an emphasis on working code motivates the Product Owner to prioritize the release of the most essential features. It also encourages developers to focus on short-term goals, and finally, it gives customers a tangible and empirically based view of the progress.
Because a release may require multiple sprints, each iteration of work builds on the previous one. Scrum is described as “iterative” and “incremental”.
Sprints do not end late or too early
Every sprint begins with the sprint planning meeting, where the Product Owner and the team discuss which user stories will be moved from the Product Backlog into the sprint backlog. It is the responsibility of the Product Owner to determine what work will be done, while the team retains the autonomy to decide how to the work has to be done. Once the team commits and starts working, the Product Owner cannot add more work to it or micromanage. He could cancel a Sprint, which shouldn’t happen often, but it would usually occur due to a sudden change in the business needs. Sprints do not end late or too early. If something is not done on time, it just passes to the backlog and gets prioritized again. If the team gets all work done earlier, the remaining time could be spent in fixing the technical debt or in doing the next user story from the backlog.
During the sprint, team members check in with each other during the daily Scrum meeting, also called the standup.
Just as every sprint begins with the sprint planning meeting, the sprint ends with the sprint review meeting, where the team presents its work to the Product Owner. During that meeting, the Product Owner determines if they have met his acceptance criteria.
The team also has a meeting at the end of each sprint to share what has worked, what hasn’t worked, and how processes could be improved. This meeting is called the sprint retrospective meeting.
Here’s a link where you will be able to find an introduction to scrum. My article is based on it.
