A sprint consisting of eight tickets, or cards, might look like the board above.
The tickets, or cards, are placed on the board by the Product Owner who pulls tickets from the Product Backlog, which have been prioritized by stakeholders. Each sprint starts off with a clean board, unless in the unusual case in where there was a card left over from the previous sprint.
The Product Owner has guesstimated the time it will take to complete all the cards and only puts as many cards on the board in the Sprint Backlog column as can be expected to be completed by the end of the sprint.
No work is pushed upon anyone. For the example in Figure 1, there is a developer team and a testing team. The testing team can only pull tickets from the column to their immediate left, which in this example is from the Dev Done column. But the team can pull as many or as few as it would like from the Dev Done column. If the team has only two people, each of them would only pull a ticket upon completion of another ticket. For this sprint, there are eight tickets, but had the project team felt like it could handle more for this sprint, there could be 10 tickets. Sometimes, there may be a ticket left over from the last sprint that never was completed. But in Figure 1, there were only eight tickets for the current sprint. The Product Owner at the beginning of this sprint pulled the most prioritized cards from the Product Backlog and put them up in the To Do column. The developers thus far, have already completed tickets one through four. The testing team has completed the tasks for Ticket 1 and is in the midst of working on Ticket 2. The developer team is currently working on tickets five and six. When someone on the Dev team completes a card, she moves it to the Dev Done column. The testers pull from the Dev Done column to do their work. If there are no Dev Done tickets and the testers are not testing anything, they can help the developers with the tickets they are currently working on in the Dev column. But as soon as a ticket moves to the Dev Done column, the testers go back to their regular duties of testing. This is the beauty of working in a DevOps culture as there is a shared responsibility for the software developers and operations build: the two teams help each other. At the end of the sprint the Product Owner packages the tickets in the Test Done column up for release.
That scenario is above is how the Scrum board works. Below are some more details about Scrum.
Every morning at the same time, everyone attends a meeting, commonly referred to as the stand-up, where each contributor to the project reports on their progress and issues that have arisen since the last stand-up. These daily meetings, which lasts about 15 minutes, hold everyone accountable for their work and allow people to discuss improvement ideas.
After the stand-up, people get to work, and over time, the cards gradually make their way across the board. For a sprint that lasts two weeks, by the middle of the second week, it’s expected that the cards have moved at least one step. It’s always a race to get everything done by the end of the sprint so the services they built can all be released. Anything that was not completed during a sprint stays on the board for the next sprint.
A retrospective meeting is held after each sprint to discuss what went well and what can be improved upon in following sprints. The team often discusses the best ways to improve the processes, tools and communication between teams and team members, as well as the action items the team will commit to for the next sprint.
Overseeing the team are the Scrum Master and the Product Owner. Although the Scrum Master has no management authority over the team, she is responsible for ensuring everyone on the team understands Scrum theory and practices and for promoting improved engineering practices. A Scrum Master who holds a certification as a Scrum Master helps the team perform better and ensures the output meets the product objectives.
The Product Owner constantly re-prioritizes the Product Backlog, ensures the product meets the needs of end users, and decides when the team needs to continue developing the product and when to release it. A product owner who holds the Certified Scrum Product Owner title helps ensure that the team works well together and the product meets business needs requirements.
In summary, the Scrum events consists of the following steps:
Scrum starts with a product owner, called the Scrum Master, who’s responsible for the project’s outcome and keeps stakeholders and DevOps informed on the project’s development. The product owner also looks at results of A/B tests to determine how users are interacting with the product and how it best functions. With Scrum, you break down your large project into phases and those phases into smaller pieces that can be completed by a cross-functional team within a prescribed time period, called a sprint, typically between two and four weeks. Once the sprint begins, you are not allowed to add in any new requirements. The Scrum process starts with a product owner creating a product backlog, a list of all that needs to be done and then prioritizing it, such as Requirement 1, Requirement 2, and 3. The requirements are set by the product owner after discussing it with the development team.
Then the product owner and development team attend the sprint planning meeting run by the Scrum Master. During sprint planning, the team pulls a small chunk from the top of product backlog items to work on during the sprint. That chunk becomes the sprint backlog, the set of tasks that the scrum teams decide to deliver for that particular sprint. As the sprint progresses, the development team performs the work necessary to deliver the backlog items by the end of the sprint. On a daily basis, the development team uses the daily scrum meeting to assess its progress. The scrum team uses a tool called a scrum board. It’s a visual representation of the workflow, which generally has four or more columns—Backlog, To Develop Test, and Done. Different tasks are placed in each column, indicating the progress of individual development items, or user stories. The cards move from the Backlog to Develop to Test and then, finally, to Done. At the end of each sprint, the development team delivers a functioning piece of the product to show for their work. The development team holds a sprint review to demonstrate to stakeholders what was accomplished during the sprint. After the sprint review, the team gathers for a sprint retrospective to discuss what went right or wrong and where they can make improvements for further sprints. Scrum teams follow an inspect-and-adapt approach. This means they improve continuously, taking lessons from their previous sprints.
Both Scrum and Kanban limit the work in progress, identify bottlenecks and improve productivity. They both break down large tasks so they can be completed efficiently and place a high value on continual improvement.
Kanban, a Japanese word that means signboard or billboard, is a workflow management system that helps teams visualize their work, become more efficient and continually improve. Originating in the manufacturing industry, Kanban was later adopted by Agile software development teams and has since been adopted by other business lines throughout a variety of industries.
Like Scrum, Kanban, uses a board to visualize and manage work. The columns could be the same as the one in Fig. 2 below or could include many other columns to suit the project and team. The work items that need to be done are put on individual cards and present important information about a task, such as the names or job roles of the people who will handle the work item, a brief description of the job being done, screenshots and technical details that help explain the task, and the amount of time the piece of work is estimated to take.
The cards for projects start off on the far-left column of the Kanban board and travel from left to right across the board, allowing team members to see the status of any work item at any point in time. If a card is held up too long in any column, everyone will be able to see that on the visualization board, allowing team members to identify any tasks that are taking longer than expected.
The Kanban Board
For any one large project, all the cards start on the far-left column, the To Do, or Backlog, column. A board typically consists of six to eight columns designed to fit the team’s needs. It could consists of the following categories of columns— 1) Backlog/To-Do, 2) Develop, 3) Develop Done, 4) Test, 5) Test Done, 6) Deploy—but also could have entirely different names. The cards are never “pushed” onto any team or column, meaning when one team finishes a task, they don’t push the card onto the next team as it may be busy with other cards and have no time to take on a new one. Instead, the team that completes a task might put it in its Done column. Then, when the following team feels ready for it, it can pick up the card and begin the tasks listed on the card. For example, for the categories listed in Fig. 2 below, the developers would move a card they just completed into a Developer Done column. That way, when the testing team is ready, it can pull the card from the Developer Done column, put it in the Test column and start work on it.
Everyone knows how it feels to have too much work pushed upon them when they already have too much work on their plate. To prevent these bottlenecks from occurring, Kanban has work-in-progress (WIP) limits. Collectively, the team decides how many cards can be in any one column at any one time. The team members may decide there may only be five cards in the Developing column and four cards in the Testing column.