According to the Scrum method, the Review Meeting should take place just after the development period of a Sprint. The purpose of this meeting is to present the Product Owner (PO) with all deliverables that were produced by the Scrum team and she has the participation of the team. During this meeting, the team has the responsibility to show the PO the work that was done, the SM has a responsibility to prevent the meeting from going off topic, and the PO has the responsibility to approve or disapprove the new features shown.

And why is it the team that presents what has been developed? This responsibility is actually one of the most important tasks for the team, and should always be respected. During planning meetings, the team commits to the PO to develop certain items from the product backlog and, at the end of the work cycle, it is the team who must show the results to the PO and take responsibility for what was produced. In addition, the team should also discuss with the PO solutions, and hear suggestions and views on what was presented.

The role of PO in this meeting is to evaluate whether what was produced is consistent with what was expected, and to validate Sprint. For a Sprint to be validated, it is necessary that the functionality delivered by the team meets the goal of the Sprint, which was agreed upon during the Planning Meeting. The fact that some of the Sprint Backlog items may be disapproved by the PO does not necessarily indicate that the Sprint was not successful. If the failed item is not related to the Sprint’s goal, it can still be validated. We just have to keep in mind that if an item is disapproved by the PO, even though part of it may have been approved, the whole task will be returned to the Product Backlog, and no points will be awarded to it. In the next Sprint, depending on the priorities set by the PO, this item can be put back into the Sprint Backlog, with the same estimate as before, and only than completed.

What was said in the post “To release versions during production is like running on asphalt” also applies to this moment in the validation work. Therefore, here at GPE, we follow the following practices: set up a script of the presentation and test the project on a local server. When mounting a roadmap presentation, we try to think of all the steps that should be taken in order to present all of the features produced, allowing the team to review the entire stream and check if something went unnoticed and needs to be reviewed. By performing the test on a local server, the team can simulate the environment that will be used in the presentation and try to identify and correct possible problems of environment configuration. These practices allow the team to have more peace of mind during the meeting and avoids problems where the answer is the now famous “on my computer it was working just fine”.

A final practice should always be used: do not wait for the Review Meeting to contact the PO. The more opinions and impressions collected from the PO during the development process, the greater the chance that the Sprint Backlog item will be approved.

Any other question? Do not forget to send your comments and watch the video lesson about this topic on our YouTube channel, Scrum University!

The post What is the Sprint Review Meeting? – Scrum FAQ appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

What is it?

In the Scrum framework, the team’s progress should be inspected daily by the rest of the Development Team, through the meeting called the Daily Scrum. This meeting aims to make the team more self-sufficient.

In the daily meeting, all team members must talk about what they have done since the last meeting, and what they are committing to have done at the next meeting. At this time, problems faced by the team as well as impediments that each member may have faced are visible to other members of the team. Technical problems should not be discussed, however, they may be addressed to allow the scheduling of a technical meeting in order to solve them. This meeting should focus on transparency of the work.

This is one of the main components of Scrum. It is where the team demonstrates daily their commitment to the progress of the Sprint. They should also maintain transparency within the team and focus on deliverable items, one of the main concepts of Scrum.

When and how?

The daily meeting, as indicated by its name, should happen daily, preferably at the end or in the beginning of the day. It should be short, about 15 minutes, and should be done with all members of the team standing before the task board. All members of the team should attend the meeting, and the Scrum Master may or may not attend.

During the meeting, each team member should answer three questions:

1. What have I accomplished since the last Daily Meeting?
2. What I will accomplish from now until the next Daily Meeting?
3. Did I have any impediments?

Enjoy and stop by at Scrum University YouTube channel and watch the video about Sprints! Until next time!

The post What is the Daily Scrum? – Scrum FAQ appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Continuing with the Scrum FAQ series, in today’s post we’ll talk about Sprints. We will see what a Sprint is, as it is created and what things shall be taken care of at the beginning, dng and at the end of a sprint.

Scrum as a development process is divided in regular cycles. Sprints are each of these cycles. According to the definition we can find in the post “Learning the Scrum terms – Glossary”, we learned that Sprint “represents a duty cycle in Scrum. This cycle can be of any size, usually 1, 2, or 4 weeks. Sprints should always have the same duration. “On every Sprint, a set of requirements (User Stories) is implemented, resulting in an increase of the product being developed.”

The diagram below represents the Sprint cycle.

Starting a Sprint – Planning

When starting the sprint, you need to make Stories for the Product Backlog, to be implemented in the cycle that is about to start. The stories in the Product Backlog should be in an order defined by the PO and must be estimated by the dev team.

Considering the Product Backlog is prioritized and estimated, the Scrum team holds a Planning meeting (Planning 1) to select the stories that will be included in the specific Sprint in order to accommodate them within the time frame of the Sprint and respecting the order defined by the PO. This set of stories included in the Sprint is called Sprint Backlog.

Once the Sprint Backlog is defined, the Sprint can then be started! At this point the development team should hold the second half of the planning meeting (Planning 2), in which each story is split up into tasks, in order to divide and control the development of each story.

Now it’s down to work! We have the stories to be implemented and the tasks to be undertaken to implement each story.

Working on a Sprint

During the Sprint, the team performs tasks for the implementing the stories in the order set by the PO. During the Sprint the team can use the Burndown chart to find out if the Sprint is delayed or ahead of the Sprint’s goal and take action if necessary.

Every day the Dev Team meets to talk about: what was done yesterday; what are the impediments; and what will be done in the today. If there are impediments, the Scrum Master seeks to resolve it as quickly as possible, so the staff can proceed with regular work on the Sprint. 

The Scrum Master also takes part of the daily meeting. It is recommended no change in time or stories of Sprint Backlog.

End of a Sprint – Review and Retrospective Meetings

At the end of the Sprint, the Sprint Review meeting is held. In this meeting, the team presents the stories that were implemented, showing the results to the PO. The PO then analyzes the outcome of each story with the Dev Team and decides whether to approve each one or not. 

The stories that are not approved are than returned to the Product Backlog and are available for inclusion in a new Sprint. At this meeting, taking advantage that the PO and the team are together, stories from the product backlog that have not been well understood by the development team may also be discussed, as well as the future of the product.

After the review meeting, the Scrum team has the Retrospective Meeting.

In this Sprint last meeting, the team shares their views and reflects on what did and did not work during the Sprint. A debate is conducted on the strengths and weaknesses of the Sprint, with the aim to reinforce what was good and finding solutions to what was bad. So, in every Sprint, the team will learn and improve process and product.

Enjoy and stop by at Scrum University´s Youtube channel and watch the video about Sprints! Until next time! 

The post What is Sprint? – Scrum FAQ appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Continuing the Scrum FAQ series,  let’s talk about Sprint Backlog.

When should it be created and what should be included in it?

We will also see which roles should be involved in setting up the Sprint Backlog.

What is it?

The Sprint Backlog represents 

everything that should be done during the next Sprint of your project. It should be made based on what the Product Owner has listen on the Product Backlogg.  Most of the items on the Product Backlog will be implemented one day, however, in order to be considered for the Sprint Backlog, they must be prepared, estimated and prioritized according to the definition of what a prepared item is, which was established in the beginning of the project.

The choice of which items will be part of the Sprint Backlog should be based on the Sprint Goal, which defines the purpose of that Sprint for Product Owner, or what he expects the product will be able to do at the end of that development cycle. This is also the goal that directs the Product Owner and Development Team to determine which items will be part of the Product Backlog and Sprint Backlog.

When and How?

The Sprint Backlog is created during the Planning Meeting, where the three Scrum roles are involved. At this time, the backlog of items to be considered must have been prepared by the Product Owner. With all the items prepared, the Development Team should estimate each item according to the Sprint Goal, and these items are than prioritized and a number of them are picked to be part of the Sprint Backlog.

This should be all based on what the Development Team can accomplish in a Sprint, and what has the highest priority.

It is advised that not all Sprint Backlog items are directly related to Goal, because if you can not finish one of them, the goal will be compromised and the Sprint will not be successful

Another important point is that the Sprint Backlog should not be changed because the Sprint Goal can not be changed. Also, including a new item in the Sprint Backlog may result in the non-completion of another item. Therefore, new items can only enter the Sprint Backlog if they are related to the Goal, and if they will not affect the items already present on the Sprint Backlog.

Do you have any more questions about the Sprint Backlog? Feel free to comment them below and be sure to watch our videos on University Scrum.

The post What is the Sprint Backlog? – Scrum FAQ appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Continuing the FAQ Scrum series, today we will talk about Stories and Product Backlog. In the post Learning the Scrum Terms – Glossary, we have learned the definition of these two terms. Here is a reminder of what they mean:

“Stories – Are the Product Backlog items that represent the part of the product to be implemented. Stories should contain a detailed description of what should be implemented.”

“Product Backlog – List of items or stories that should be implemented to create the desired product or project development.”

Ok, but how does this work in reality?

Let’s start with the Stories:

As stated above, they represent a part of the product to be implemented because the Product Owner (PO) requested it. Generally, the stories are raised during a meeting between the team, Scrum Master and PO and there is no level of granularity pre-set for them. A story can described as anything from changing a label on the screen to the creation of a new system functionality. The important thing is to check that what should be implemented to make the complete the Story was really understood by the team.

It is possible that in some stories the team feels the need to split the task required in order to have greater control over what should be done. That is not a problem. In fact, it is highly recommended. During the meeting, the team can and should suggest to the PO that a particular story is divided into different ones or has changed its description. The function of the team is not only to develop the desired functionality, but also to find, along with the PO, the best way to complete each story.

Now let’s talk about the Product Backlog:

All Stories the PO comes up with should be on the Product Backlog. In it are listed all the needs identified for the project, sorted by priority by the PO. In addition, the Product Backlog is never complete. It should be updated as the project development progresses and new needs are met. At each iteration of the project, it is possible that new stories enter the Product Backlog and new priorities are established.

Before starting the development, each story should be divided into tasks. Each task should represent a step that must be completed within one day of work to finalize the functionality included in that story. An important point to be considered when establishing the duties of a story is that, ideally, the whole team must work on developing it. That way everyone can share knowledge related to that Story and also increases staff productivity.

And on your team? Are the concepts of Story and Product Backlog are already well understood? Enjoy watching the tutorial on the Scrum University Youtube channel about the Product Backlog.

* To learn about the roles on Scrum, take a look on Scrum FAQ Which are the roles on Scrum?

The post Stories and Product Backlog – Scrum FAQ appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.