In our previous lesson, we talked about creating disclosure and acceptance criteria for user stories.
In this lesson, we will talk about the common understanding of the content of a story and sizing the story, in other words, estimation.
Let's see this through an example.
The product owner initiates a study with the Scrum team to further evaluate the Starting Page item. Let's take a look at the conversation between our team member Mr. Alex, product owner Ms. Suzan and Scrum Master Mr. Frank.
Alex: “I thought of something, I want to share it with you. I think an admin panel is needed on the start page to easily change the phone number, address information or images to be used.”
Suzan: “Yes, you are right, we will definitely need this in the future, you thought very well.”
Alex: “Then we need to add this feature to the product backlog items as well.”
Suzan: “You are right, Alex. So guys, in which order do you think I should add this item?”
Frank: “As the product owner, you can add the user story to the order you want and change the order whenever you want. Over time, the urgency and importance of needs will become more shaped, making it easier to rank.”
In our next lessons, we will examine in detail the different techniques for prioritizing.
Suzan: “If you have no further questions, I suggest doing sizing work for the Start Page Creation item.”
Sizing or Estimating is a prediction of the effort required to perform a particular task. A prediction is never a commitment or a promise. Estimates include assumptions, uncertainties and risks.
Estimations are made on unitless values in the Scrum approach. In other words, the relative size approach is taken as a basis. Let's explain with a simple example. When you look at a large building, it is very difficult to tell how many floors it has, rather it is much easier to compare two buildings and tell which one is bigger. This is called relative sizing.
Another similar point of view could be as follows. For example, let a walk in the park be represented by just the number 1 in terms of effort. In contrast, the difficulty and complexity of climbing a mountain like Everest is represented by the number 100. Thus, we have determined the criteria that we will use as a scale. After that, we can speculate when considering the magnitude of our business, by thinking about walking in the park, climbing a slope or a small hill, climbing a mountain near our city, and finally reaching the summit of Everest. There is no right or wrong with the numbers given during estimation. Each team member makes an estimate, considering the difficulty and complexity of the job for himself.
Team members write their predictions for the item “preparing the starting page” independently on a piece of paper and show it to each other at the same time. The aim here is to ensure that they are not influenced by each other and to ensure that each makes an independent guess.
For example, let them write numbers as 9 - 12- 15- 22 - 28. The Scrum Master asks team members to revise these numbers in accordance with the following number sequence.
1- 2- 3- 5, 8, 13, 20, 40 and 100 - These numbers are the sequence of numbers called planning poker.
Thus, the estimates given are revised to 8 -13 - 13 -20 and 20. The aim here is to categorize and place the estimates that are close to each other in a similar scale.
After these estimates, team members discuss to determine what the differences between the estimates are. A team member who chooses the number 20 says that the logo to be put on the site is not digitally ready and needs to be drawn. Another team member states that professional photography is required for the pictures to be used on the home page. The other team members admit that they did not think about these details and the team agree on the number 20 as the difficulty level of the work. Then, Frank reminds the team.
Frank: “Guys, I would like to remind you that the equivalent of 20 is not 20 hours or 20 days. But from now on, when estimating other items, it will be easier for us to compare it to this item and rate it for difficulty and complexity.”
By estimating other items, each item in the backlog is given story points.