With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles. Out of a wide range of topics, you can choose to learn from the real-world experiences by practitioners in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc.
Traditionally, Lean measurements have a lot to do with time-based performance. In addition, quality and cost can also influence these metrics. These measurements need to be expanded outside of manufacturing to include related aspects, such as safety, amount of work, complexity, or any risk/uncertainty in performing it. For this reason, it is convenient to look at other disciplines, such as working in Scrum Teams, to incorporate new metrics and tools.
Measurements or metrics should be defined based on objectives. Specific objectives must be defined. Based on well-defined objectives, you will easily see what needs to be measured.
Lean Manufacturing is a concept that improves quality, reduces cost, empowers people, and increases customer satisfaction. It improves business performance through waste/scrap disposal and non-value-added activities, as well as the people involved in a continuous improvement system (Kaizen). Typical metrics in this discipline could be a reduction of production cycle time, waste control, inventory management, the creation of customer value, continuous improvement through employee empowerment, and the receipt of employee engagement by creating mutual trust and respect.
Metrics should help make waste visible in business processes, where information must flow. Some typical metrics are:
Story Points are a unit of measurement to express or estimate the overall effort that would be required to manufacture an element of a product or any other part of the production. A Story Point is an arbitrary measure used by Scrum Teams. The Story Points is used to measure the effort required to implement a story (fabrication of an element). In simple terms, it is a number or metric that indicates to the team how difficult/simple the story is (work to be done) and is directly related to complexity, unknowns, and effort.
When we calculate with Story Points, a value in points is assigned to each element. The assigned values or premiums are not important, what matters are the relative values between the different stories. For example, a story that is assigned a 2 should be twice as complex as a story that is assigned a 1.
Instead of assigning 1, 2, and 3... 100, 200, and 300 could have been allocated... or 1 million, 2 million, and 3 million. It's about the relationships, not the real numbers that matter. Semantic terms of the very small, small, medium, large, extra-large types can also be used. Generally what is used is the Fibonacci series to allocate premiums.
The participation of everyone (developers, designers, implementers... and even customers) is the key. Each team member brings a different perspective on the product and the work needed to deliver a story.
Because Story Points represent the effort to develop a story, a team's estimate should include everything that can affect the effort. This could include:
Story Points are a relative term and do not refer directly to actual hours. This makes it easy for Scrum Teams to think abstractly about the effort needed to complete a story. When estimating with Story Points, make sure to consider each of the above factors. Let's see how each affects the estimate of effort provided by Story Points.
Certainly, if there is more work, the estimate of effort must be higher. Consider the case of two web page developments. The first page has only one field and a label that prompts you to enter a name. The second page has 100 fields to be filled in as well, simply with a little text.
The second page is no more complex. There are no interactions between the fields and each one is nothing more than text. There is no extra effort on the second page. The only difference between the two pages is that there is nothing else to see on the second page.
The second page should have more Story Points. You probably shouldn't receive 100 times more points even though there are 100 times more fields. It is, in short, an economy of scale and perhaps making the second page have only 2 or 3 or 10 times more effort, at most than the first page.
The amount of risk and uncertainty is an element of the production line that affects the estimation of the Story Points of each element or part of the product. If a team is asked to estimate an element of the production line and it is not clear that element, the uncertainty should be reflected in the estimate. If the implementation of a new function in production involves the change of a certain part of the process and you are not sure how it will affect the current process, this risk should be reflected in the estimate. If you do not have tests that can standardize and automate a new production process, that risk should also be reflected in the estimate.
Complexity should also be considered when providing an estimate in Story Points. Going back to the previous example of developing a web page with 100 trivial text fields with no interactions between them. Now you have another website also with 100 fields. But some are calendar date fields; others are text fields, such as phone numbers or tax identification numbers; other fields do checksum validations just like with credit card numbers.
This screen requires interaction between fields. If the user enters a Visa card, a three-digit CVV field is displayed. However, if the user enters an American Express card, a four-digit CVV field is displayed. Even though there are still 100 fields on this screen, these fields are more difficult to implement. The web is more complex and therefore it's going to take longer to implement. There is more chance that the developer will be wrong, he has to make backups and fix them. This additional complexity should be reflected in the estimate provided.
It may seem impossible to combine these three factors into one number and arrange them as an estimate. However, it is possible, since effort is the unifying factor. These estimators consider the amount of effort it will take to do the work required by each element on a production line. This is usually done by taking into account the risk that a problem occurs and the impact when it occurs.
Estimators also take into account the complexity of the work to be done. Work that is complex will require more time and dedication, may require more trial and error experimentation, perhaps more feedback with a client may take longer to validate, and may need more time to correct errors. By doing a retrospection over time, you can get feedback for the team to incorporate perceptions from previous iterations, including the accuracy of their estimates. Many Agile tools that use Story Points is reflecting and re-calibrate the estimate.
An estimate with Story Points should include everything that involves manufacturing an element of the production line to the end. If the definition of a team includes the creation of tests to validate the story automatically, the effort of creating those tests must be included in the estimate using Story Points. The use of Story Points can be a difficult concept to understand at first. But the effort to fully understand what Story Points represent and how they are affected by the amount of work, complexity, and any risk or uncertainty at work will be worth the grief.
To continue growing and providing added value to our customers, it is necessary to carry out an excellent work of parameterization and definition of the metrics of our business. Lean provides us with a very good series of metrics, but we can resort to other tools from other disciplines such as Scrum that will enrich our production processes and improve our organization.