Scrum sprint




Scrum

Visão geral

Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.

No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo:

Scrum Methodology

The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.

10th
OCT

Scrum Sprint

Posted by admin under Scrum Basics

In the Scrum method of Agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. Scrum sprints used to be 30 days long, but today we advise one-week or two-week sprints. If a team has trouble doing a two-week sprint, we suggest trying a one-week sprint to see where the snags are.

During each sprint, a team creates a potentially shippable product increment, no matter how basic that product is. Working within the boundaries of such an accelerated timeframe, the team would only be able to build the most essential functionality. Placing an emphasis on working code motivates the Product Owner to prioritize a release’s most essential features, encourages developers to focus on short-term goals, and gives customers a tangible, empirically based view of progress. Scrum is iterative and incremental. Because a release may require multiple sprints, each iteration of work builds on the previous (incremental), often replacing/discarding some of the previous work as more is learned (iterative).

Every sprint begins with the sprint planning meeting, in which the Product Owner and the team(s) discuss which stories will be moved from the Product Backlog into the sprint backlog. It is the responsibility of the Product Owner to determine what work the team will do, while the team retains the autonomy to decide how the work gets done. Once the team commits to the work, the Product Owner cannot add more work or micromanage. The Product Owner can cancel a Sprint, which shouldn’t happen often, and would usually occur due to a sudden change in business needs.

During sprint execution, the team develops code and automated tests simultaneously, ideally using techniques such as Test Driven Development (TDD), pair programming, and continuous integration. Agile teams also learn to automate their system testing, performance testing, load testing, etc. so the product can be completely shippable every sprint, whether or not it has all the features it will ultimately need. This type of collaboration is more likely to occur in a team room. Good scrum teams are cross functional, meaning they have skills in development, testing, business domain (requirements) expertise, UI skills, etc. They focus on learning rather than traditional microefficiencies. Agile approaches minimize handoffs and phases.

During the sprint, team members check in with each other at the daily Scrum meeting, also called the standup.

After sprint execution, we conduct a sprint review meeting, in which the team demonstrates the potentially shippable product increment to the Product Owner and everyone else who’s interested.

The team also gathers in private at the end of each sprint to reflect on how things went and what they’d like to change. This meeting is called the sprint retrospective meeting.

In Large Scale Scrum, sprints are similar, but there are multiple teams pulling work from one Product Backlog, prioritized by one Product Owner (usually with advisors). Multiple backlogs and Product Owners are harmful to large scale agility. Also teams are responsible for their co-ordination with the world outside them, including other teams. Scrum does not use traditional co-ordination roles such as project manager and PMO, as these interfere with team self organization.

Reader’s Comments

  1. Peoria Osterelli | December 5th, 2016 at 8:34 am

This is my 2nd company using this methodology. Very meeting intensive, get nothing done correctly technology. Break things rapidly and rapid personnel turn over… this leads to bad company hiring reviews and inability to hire people, ultimately locking you out of the market and ending up in the mercy of consultants. Meanwhile you pile crap up on your DBA’s to the point where they don’t even have time to review, while constantly losing your talent and knowledge base. Sure I want to use that technology. RAD = Rapid Application Destruction.

Dave, what you’re describing doesn’t sound anything like collaboration to me. It sounds more like people handing off work to each other. The purpose of Scrum’s timeboxes is to expose things like that.

Shailesh, I seem to be repeating myself, but in Scrum the build doesn’t “go to QA.” Testing is integrated throughout. Consider spending some time with the e-learning modules to get an idea how this works in practice. Also, why do you have a plan for the next 6 sprints? In Scrum we plan one Sprint at a time.

@Rashi Jain – very fair point. I have just started with a team and at the sprint meeting the feature is discussed. Then someone goes off to spec the database changes and web service definitions, while the rest of us wait. Once the spec is done the middle ware guy and the web guy can write some code to the spec but there is a limit to what you can do without the layer below to build against. In my case our sprint meeting was a week ago. I wrote all the code to spec that I could in one day. The middle ware guy waited a few days for the database scheme to be settled, then started the webservices. I have been waiting for 6 days since the sprint meeting for the web services. That is a lot of waiting! Shouldn’t there be some sort of offset? I feel like I should be writing to their sprint 1 work while they start their sprint 2 data modeling.

-If there is development there are going to be bugs, what should be the ideal timeline for a build to go to QA for a 2 weeks sprint?
-What if bugs are reported post Sprint complete date, they goes as backlog ?
-While planning for sprint, is it good idea to keep aside some efforts for bug fixing ?
I have plan for next 6 sprints, but due to bugs reported my sprint is pushing, please suggest

In scrum TDD is great idea and works really well, the query I have is in relation to System Test, Integration Test and performance testing, how do you ensure all that is covered in a 3 week sprint.How do you ensure the independence of test, in the case of In-team development test they are trying with the team to make the delivery but in the case of independent test they are trying to break the product. Both have different agendas, how do you ensure the quality of product for delivery when all other test is outside the sprint and thus break code after definition of done is met. Is there anything in agile for including system test, performance test etc in sprint and is that really possible in 3 weeks??
Would welcome your thoughts?

In Scrum (and most other Agile approaches) there is no separate testing team. One cross-functional team is responsible for a properly tested product increment every Sprint. This means automated tests are written at the same pace as the code, or in Test Driven Development (TDD), automated tests are written a few minutes before the code that they test.

In a agile developement if the sprint is of 15 days and testing team receives the code on 12th day of the sprint.how the testing team should complete the testing

Great high-level summary, well written. Our company just started this recently (on our 6th sprint now), and I was a little confused about the pacing, being a pig. Fixed me right up!

@Sam: We timebox the meetings. For instance, the daily meeting is 15 minutes long. Also consider the possibility that collaborating with each other is part of “doing the work.”

So with all of these daily/weekly meetings, who is doing the work? When does the work ever get done?

Really, very nice stuff to get start up with Scrum method…….

Scrum and sprint planning tools

In this article

Azure Boards | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Once you’ve defined and selected the sprints for your team, you can start using the following tools to plan your sprint.

Track team capacity

At the start of each sprint, you’ll want to plan the work that your team can commit to. The three Agile tools that support this work include the sprint backlog, capacity planning, and capacity bars. The sprint backlog contains a filtered subset of backlog items whose iteration path corresponds to the current sprint.

Team capacity planning tool

By setting team capacity, the team knows exactly the total number of work hours or days the team has for each sprint. With this tool, you set individual team member capacity as well as days off. And, conveniently, you can set holidays or shared days off taken by the entire team.

Setting capacity for each team member working during a sprint causes the capacity bar for that individual to appear.

You set recurring days off, such as weekends, through team settings.

Individual and team capacity bars

With capacity bars, you can quickly see who is over, at, or under capacity. Capacity bars update with each of these activities:

Tasks are assigned with non-zero remaining work

Change in remaining work

Date change within the sprint cycle. Individual and team capacity always reflects their capacity from the current day till the end of the sprint.

Here’s how to interpret the capacity colors:

Update tasks, monitor burndown

During a sprint, your team can use the taskboard and sprint burndown chart to track their progress. Your sprint burndown chart provides you with an at-a-glance visual to determine if your team is on track to meet their sprint plan.

Your Taskboard provides an interactive progress board for work required to complete the sprint backlog. During your sprint you’ll want to update the status of tasks and the remaining work for each task.

Updating tasks daily or several times a week yields a smoother burndown chart.

Sprint burndown chart

You use the sprint burndown chart to mitigate risk and check for scope creep throughout your sprint cycle. The burndown chart reflects the progress made by your team in completing all the work they estimated during their sprint planning meeting.

The ideal trend line always indicates a smooth and steady burndown. The blue area, however, represents what’s actually going on. It shows the buildup of work as team members add tasks and the reduction of work as team members complete those tasks.

Velocity and forecast

While you use sprint planning and tracking tools for each sprint, you use the velocity and forecast tools to estimate work that can be completed in future sprints.

Velocity provides a useful metric for gaining insight into how much work your team can complete during a sprint cycle. And, the forecast tool provides a means for determining how much work your team can complete within a sprint based on a specified team velocity.

After your team has worked several sprints, they can use the velocity chart and forecast tool to estimate work that can be accomplished in future sprints.

Velocity chart

Each team is associated with one and only one velocity chart. The green bar within the chart indicates the total estimated effort (story points or size) of backlog items (user stories or requirements) completed within the sprint. (Blue corresponds to the estimated effort of items not yet completed.)

Velocity will vary depending on team capacity, sprint over sprint. However, over time, the velocity should indicate a reliable average that can be used to forecast the full backlog.

By minimizing the variability of backlog item size—effort or story points—you gain more reliable velocity metrics.

Forecast tool

You can use the forecast tool to get an idea of how many and which items you can complete within a sprint.

*By plugging in a velocity, you can see which items are within scope for the set of sprints the team has selected. As shown here, a velocity of 15 indicates that it will take three sprints to complete the work shown. *

Related articles

If you work with several teams, and each team wants their own backlog view, you can create additional teams. Each team then gets access to their own set of Agile tools. Each Agile tool filters work items to only include those assigned values under the team’s default area path and iteration path, which you configure via the Set team defaults .

Feedback

We’d love to hear your thoughts. Choose the type you’d like to provide:

Scrum and best practices

In this article

Azure Boards | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Sprint planning meetings

Much of sprint planning involves a negotiation between the product owner and the team to determine the focus and work to tackle in the upcoming sprint. It’s useful to time-box the planning meeting, restricting it to 4 hours or less.

In the first part of the meeting, your product owner meets with your team to discuss the user stories that might be included in the sprint. Your product owner will share information and answer any questions that your team has about those stories. This conversation might reveal details such as data sources, user interface layout, response time expectations, and considerations for security and usability. Your team should capture these details within the backlog items form. During this part of the meeting, your team learns what it must build.

As you plan your sprints, you may discover additional requirements that you should capture and add to your backlog. Before your sprint planning meeting, you’ll want to refine your backlog to make sure that it is well defined and in priority order.

Also, setting a sprint goal as part of your planning efforts can help the team stay focused on what’s most important for each sprint.

After you’ve planned your sprint, you may want to share the plan with key stakeholders.

You can learn more from these resources:

Set sprint goals

Scrum teams use sprint goals to focus their sprint activities. They often set this goal during their sprint planning meeting. The goal summarizes what the team wants to accomplish by the end of the sprint. By explicitly stating the goal, you create shared understanding within the team of the core objective. The sprint goal can also help guide the team when conflicts arise around priorities.

Tips from the trenches: Define sprint goals

The sprint goal defines what the product owner and the team consider as the ultimate target to accomplish that sprint. It’s not a random selection of backlog items that don’t really have a relationship, but a short piece of text that captures what the team should try to accomplish. Normally the product owner comes up with the sprint goal before selecting a number of items for the next sprint. The items for that sprint should all fit that common goal.

Sprint goals can be feature oriented, but might also have a large process component such as deployment automation or test automation.

  • This sprint we will focus on a very simple user story and we will use it to prove that the proposed solution will work.
  • This sprint will revolve around implementing the security features that will properly secure the administration section of the website.
  • This sprint will be about integrating the most important payment gateways so that we can start collecting money.

Setting the sprint goals helps the team to stay focused. It will make it easier to define priority of tasks within a sprint and it will probably help limit the number of stakeholders and end-users that are involved.

During the sprint review the most important question you should ask yourself is whether you managed to achieve the sprint goal. How many stories you actually completed comes second. If the goal is accomplished, the sprint succeeds, even if not all stories were finished.

Contributed by Jesse Houwing, Visual Studio devops Ranger and a senior consultant working for Avanade Netherlands.

Tips for successful triage meetings

Fixing bugs represents a trade-off with regards to other work. Use your triage meeting to determine how important fixing each bug is against other priorities related to meeting the project scope, budget, and schedule.

  • Establish the team’s criteria for evaluating which bugs to fix and how to assign priority and severity. Bugs associated with features of significant value (or significant opportunity cost of delay), or other project risks, should be assigned higher priority and severity. Store your triage criteria with other team documents and update as needed.
  • Use your triage criteria to determine which bugs to fix and how to set their State, Priority, Severity, and other fields.
  • Adjust your triage criteria based on where you are in your development cycle. Early on, you may decide to fix most of the bugs that you triage. However, later in the cycle, you may raise the triage criteria (or bug bar) to reduce the number of bugs that you need to fix.
  • Once you’ve triaged and prioritized a bug, assign it to a developer for further investigation and to determine how to implement a fix.

Manage your technical debt

Consider managing your bug bar and technical debt as part of your team’s overall set of continuous improvement activities. You may find these additional resources of interest:

Tips from the trenches: Agile Bug Management: Not an Oxymoron

by Gregg Boer, Principal Program Manager, Visual Studio Cloud Services at Microsoft

Every Sprint, Address any Known Bug Debt

Every sprint, the team looks at any bugs remaining in the bug backlog and allocates capacity to get that known set of bugs down to zero, or near-zero. Whether this is one day, one week or the entire sprint, they fix the bugs first. Bugs found later, within the sprint, are not considered part of that initial commitment. Unless they’re very high priority, they’re put on the bug backlog for the next sprint.

Many teams work in a commitment-based organization, where management places a high value on a team’s ability to meet their commitments. Doing capacity planning against a known set of bugs makes sprint planning more deterministic, increasing their chance to meet commitments. Any new bugs discovered during the sprint are not a part of the initial commitment, and will be tackled next sprint.>

Managing Bug Debt across an Enterprise

An organization transitioning to a culture where debt is continually eliminated likely is dealing with the following question: How do you get teams to reduce their bug count without telling them exactly what to do? Leadership wants the team to change, yet gives the team autonomy to determine how they change. One option is to use a bug cap.

For example, consider a bug cap of three bugs per engineer. This means a team of 10 people should not have more than 30 bugs in its bug backlog. If the team is over its cap, it’s expected to stop work on new features and get under the bug cap. A team is expected to be under its cap at all times, but the team decides how it wants to do that. The bug cap ensures that bug debt is never carried for too long, and the team can learn from the mistakes that causes the bugs to be injected in the first place.

Remember that the bug cap represents the bugs in the bug backlog. It does not include bugs found and fixed within the sprint in which a feature is developed. Those bugs are considered undone work, not debt.

While bugs contribute to technical debt, they may not represent all debt.

Poor software design, poorly written code, or short-term fixes in place of best, well-designed solutions can all contribute to technical debt. Technical debt reflects extra development work that arises from all these problems.

You need to track work to address technical debt as PBIs, user stories, or bugs. To track a team’s progress in incurring and addressing technical debt, you’ll want to consider how to categorize the work item and the details you want to track. You can add tags to any work item to group it into a category of your choosing.

Role of the Scrum Master

Scrum Masters help build and maintain healthy teams by employing Scrum processes. They guide, coach, teach, and assist Scrum teams in the proper employment of Scrum methods. Scrum Masters also act as change agents to help teams overcome impediments and to drive the team toward significant productivity increases.

Core responsibilities of Scrum Masters include:

    Support the team to adopt and follow Scrum processes. For example, you should not let the daily Scrum meeting become an open discussion that lasts 45 minutes.

Guard against the product owner or team members from adding work after the sprint begins.

Clear blocking issues that prevent the team from making forward progress. This might require you to perform small tasks, such as approving a purchase order for a new build computer or resolving a conflict within your team.

  • Help the team work to resolve conflicts and issues that arise and learn from the process.
  • Ask questions that reveal hidden issues and confirm that what people are communicating is well understood by the entire team.
  • Identify and safeguard the team from potential issues becoming major issues. Just as it’s cheaper to fix a bug soon after it’s discovered, it’s also easier and less disruptive to fix a team issue when it’s small and manageable.
  • Prevent the team from presenting incomplete user stories during a sprint review meeting.
  • Gather, analyze, and present data to business stakeholders in a way that demonstrates how the team is improving and growing. For example, if your team has significantly increased the amount of value that it has delivered while generating fewer bugs, make the value visible through regular communications to business stakeholders.
  • Good Scrum Masters possess or develop excellent communication, negotiation, and conflict resolution skills. They actively listen to not only the words that people say and write but also how they deliver their messages (their body language, facial expressions, vocal pace, and other nonverbal communication).

    Just as it’s cheaper to fix a bug soon after it’s discovered, it’s also easier and less disruptive to fix a team issue when it’s small and manageable before it grows into a major issue.

    Daily Scrum meetings

    Daily Scrum meetings help keep a team focused on what it needs to do the next day to maximize the team’s ability to meet its sprint commitments. Your Scrum Master should enforce the structure of the meeting and ensure that it starts on time and finishes in 15 minutes or less.

    Three aspects of successful Scrum meetings are:

    • Everyone stands up (this helps to keep the meetings focused and short)
    • They start and end on time and occur at the same time in the same location each day
    • Everyone participates, each team member answers the three Scrum questions:
      • What have I accomplished since the most recent Scrum?
      • What will I accomplish before the next Scrum?
      • What blocking issues or impediments might affect my work?

    Team members should strive to answer their questions quickly and concisely. For example:

    «Yesterday, I updated the class to reflect the new data element that we pull from the database, and I got it to appear in the interface. This task is complete. Today, I will ensure that the new data element is correctly calculating with the stored procedure and the other data elements in the table. I believe I will accomplish this task today. I will need someone to review my calculations. I have no impediments or blocking issues.»

    This response conveys what was accomplished, what will be accomplished, and that the team member would like some help looking at the code.

    Contrast with this next example:

    «Yesterday, I worked on the class, and it works. Today, I will work on the interface. No blocking issues.»

    Here, the team member doesn’t provide enough detail about what class they worked on nor which interface components they’ll complete. In fact, the word accomplished never came up.

    It’s important that no one interrupts during report outs. Each person must have sufficient time to answer the three questions.

    More in-depth and follow-up discussions should take place after the meeting, as people return to their desks or, if a significant amount of conversation is necessary, in a follow-up meeting.

    Many teams delay discussions by using the «virtual parking lot» method. As topics come up that a team member believes warrants further discussion, they can quietly walk to a whiteboard or flipchart and list the topic in the parking lot. At the end of the meeting, the team determines how they’ll handle the listed items.

    Sprint review meetings

    Conduct your sprint review meetings on the last day of the sprint. Your team demonstrates each product backlog item that it completed in the sprint. The product owner, customers, and stakeholders accept the user stories that meet their expectations and identify any new requirements. Customers often understand their additional needs more fully after seeing the demonstrations and may identify changes that they want to see.

    Based on this meeting, some user stories will be accepted as complete. Incomplete user stories will remain in the product backlog, and new user stories will be added to the backlog. Both sets of stories will be ranked and either estimated or re-estimated in the next sprint planning meeting.

    After this meeting and the retrospective meeting, your team will plan the next sprint. Because business needs change quickly, you can take advantage of this meeting with your product owner, customers, and stakeholders to review the priorities of the product backlog again.

    Sprint retrospective meetings

    Retrospectives, when conducted well and at regular intervals, support continuous improvement.

    The sprint retrospective meeting typically occurs on the last day of the sprint, after the sprint review meeting. In this meeting, your team explores its execution of Scrum and what might need tweaking.

    Based on discussions, your team might decide to change one or more processes to improve its own effectiveness, productivity, quality, and satisfaction. This meeting and the resulting improvements are critical to the agile principle of self-organization.

    Look to address these areas during your team sprint retrospectives:

    • Issues that affected your team’s general effectiveness, productivity, and quality.
    • Elements that impacted your team’s overall satisfaction and project flow.

    What happened to cause incomplete backlog items? What actions will the team take to prevent these issues in the future?

    For example, consider a team that had several tasks that only one individual on the team could perform. The isolated expertise created a critical path that threatened the sprint’s success. The individual team member put in extra hours while other team members were frustrated that they could not do more to help. Going forward, the team decided to practice eXtreme Programming to help correct this problem over time.

    As a team, work to determine whether to adapt one or more processes to minimize the occurrence of problems during the sprint.

    In some cases, your team may need to do some work to implement an improvement. For example, a team that found themselves negatively impacted by too many failed builds decided to implement continuous integration. Because they didn’t want to disrupt process, they allocated a few hours to set up a trial build before turning it on in their production build. To represent this work, they created a spike and prioritized that work against the rest of the product backlog.

    Related articles

    Feedback

    We’d love to hear your thoughts. Choose the type you’d like to provide:

    What is a Sprint?

    In the Scrum Framework all activities needed for the implementation of entries from the Scrum Product Backlog are performed within Sprints (also called ‘Iterations’). Sprints are always short: normally about 2-4 weeks.

    Each Sprint follows a defined process as shown below:


    The Sprint Process

    Each Sprint start with two planning sessions to define the content of the Sprint: the WHAT-Meeting and the HOW-Meeting. The combination of these two meeting are also defined as Sprint Planning Meeting. In the WHAT-Meeting the Scrum Team commits to the User Stories from the Scrum Product Backlog and it uses a HOW-Meeting to break the committed User Stories into smaller and concrete tasks. Then implementation begins.

    At the end of the Sprint a Sprint Review Meeting is conducted to allow the Scrum Product Owner to check if all of the committed items are complete and implemented correctly. Additionally a Sprint Retrospective Meeting is conducted to check and improve the project execution processes: What was good during the Sprint, what should continue as it is and what should be improved.

    During the Sprint a short daily Standup-Meeting (Daily Scrum Meeting) is held to update the status of the items and to help self-organization of the team.

    Your Scrum Training
    Table of Contents