Expert Scrum Master / PSC I - Exam Review

What Are Story Points? by Mike Cohn

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.

What Goes Into a Story Point?

Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include:

• The amount of work to do
• The complexity of the work
• Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors. Let’s see how each impacts the effort estimate given by story points.

The Amount of Work to Do

Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text.

The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page.

The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.

Risk and Uncertainty

The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item.

If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.

If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate.

Complexity

Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them.

Now think about another web page also with 100 fields. But some are date fields with calendar widgets that pop up. Some are formatted text fields like phone numbers or Social Security numbers. Other fields do checksum validations as with credit card numbers.

This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the user enters an American Express card, a four-digit CVV field is shown.

Even though there are still 100 fields on this screen, these fields are harder to implement. They’re more complex. They’ll take more time. There’s more chance the developer makes a mistake and has to back up and correct it.

This additional complexity should be reflected in the estimate provided.

Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity

It may seem impossible to combine three factors into one number and provide that as an estimate. It’s possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item.

Estimators then consider how much effort to include for dealing with the risk and uncertainty inherent in the product backlog item. Usually this is done by considering the risk of a problem occurring and the impact if the risk does occur. So, for example, more will be included in the estimate for a time-consuming risk that is likely to occur than for a minor and unlikely risk.

Estimators also consider the complexity of the work to be done. Work that is complex will require more thinking, may require more trial-and-error experimentation, perhaps more back-and-forth with a customer, may take longer to validate and may need more time to correct mistakes.

All three factors must be combined.

Consider Everything in the Definition of Done

A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.

Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work will be worth it.

What is Management 3.0?

www.management30.com

We’ve realized that almost every industry is ripe for change and ready for a new view

 on management. Management 3.0 is that future of management.

Management 3.0 is a movement of innovation, leadership and management.

 Management 3.0 is redefining the definition of leadership with management as a 

group responsibility. It’s about working together to find the most efficient way for a 

business to achieve its goals while maintaining the happiness of workers as a priority.

Management 3.0 is a global management revolution that brings together

 thousands of project managers, mid-level managers, CEOs and entrepreneurs, 

developing solutions together, using games to encourage employee feedback

 and team collaboration.

You don’t want theories and soft management science, you want hands-on approaches

 that can become solutions for increasing employee engagement and improving results.

 You want to build a future.

Management 3.0 is the future of management.

SAFE (Scaled Agile Framework )

is an Agile software development framework designed by Scaled Agile, Inc. It consists of a knowledge base of integrated patterns intended for enterprise-scale Lean-Agile development.

SAFe synchronizes alignment, collaboration, and delivery for large numbers of agile teams.

But first let's remember some basic Agile concepts...

                                                            http://agilemanifesto.org/

and... THE AGILE PRINCIPLES

These values are important because in the Agile culture, our main focus is on value creation instead of on single process compliance. For this reason, in the Agile Methods, we have a lightweight approach in terms of the software requirements discipline. 


SAFe is organised into three levels: Team, Program and Portfolio. Each level has a set of roles, events and rules. We can use this structure to help the way to scale the content into big companies or into big products/projects

In a large structure we have:

Theme - Represent the set of initiatives which drive the enterprises investment in systems, products and applications."

Epics - Epic, then, represent the highest level expression of a customer need as this hierarchical graphic shows.

Features - Are services provided by the system that fulfill stakeholder needs.

It's important to note that one theme can involve many Epics and each Epic may be detailed into many Features and each Feature has many User Stories. We can see this behavior in the image below.

Each kind of item is discovered and managed at each level of SAFe. Thus, at Portfolio level, we have Themes and Epics. At this level, there is an artifact called Portfolio Backlog. The Portfolio Backlog is a prioritised list of Epics. 

At Program level, we work with Features derived from Epics. These Features are also organised and prioritised into the artifact known as Program Backlog. At the end, we have the Team Level. At this level, the teams can breakout each Feature in many User Stories. 

Principles of SAFe

SAFe is based on a number of immutable, underlying Lean and Agile principles. These are the fundamental tenets, the basic truths and economic underpinnings that drive the roles and practices that make SAFe effective:

1.   Take an economic view

2.   Apply systems thinking

3.   Assume variability; preserve options

4.   Build incrementally with fast, integrated learning cycles

5.   Base milestones on objective evaluation of working systems

6.   Visualize and limit WIP, reduce batch sizes, and manage queue lengths

7.   Apply cadence (timing), synchronize with cross-domain planning

8.   Unlock the intrinsic motivation of knowledge workers

9.   Decentralize decision-making

The SAFe framework  www.scaledagileframework.com

SAFe: differences between Nexus and LeSS

Nexus:

• Scrum.org's framework for scaling Scrum
• Intended for 3-9 Scrum teams 
• Adds an "Integration Team" that focuses on dependencies, interoperation, and integration between Scrum teams.  "The Nexus Integration Team consists of individuals who are skilled in the use of tools and practices associated with scaled development work."
• Simplistically, the Nexus framework takes the various roles and ceremonies of Scrum and adds "Nexus" in front of them.  For example, "the Nexus Daily Scrum".
• Nexus is heavily focused on this integration/SOS role.  It does not seem to cover other organizational considerations like Org Structure the way that LeSS does.

                                                            ------------------------------------------------------------

LeSS (Large-Scale Scrum) 

LeSS is a product development framework that extends Scrum with scaling rules and guidelines without losing the original purposes of Scrum.

LeSS stands for the general techniques for scaling Scrum and Agile Development to more than one team and it is the name for the basic LeSS Framework which works up-to around 8 teams. 

The second LeSS Framework is named "LeSS Huge" and introduces additional scaling elements for development up to hundreds of developers.

LeSS can be thought of as regular Scrum applied in multiple levels to suit large-scale development: it is a minimal framework that offers a high degree of flexibility at implementation. It is non-prescriptive, and merely gives suggestions.

 LeSS builds on “basic” Scrum in that it recommends organizing several feature teams under one Product Owner (PO).

 Framework-2, also referred to as LeSS Huge, then adds further APOs (Area POs) to enable scaling. Teams are coordinated with Sprint Planning meetings, and further meetings may be added to help collaboration.

LeSS is a great choice for small organizations that are growing quickly, and are looking for a framework that helps scale Scrum along with their organization. It allows flexibility over rules, which is both its advantage and its major risk factor: large enterprises may shy away from it in favor of a more structured framework.

LeSS Huge Framework

SCRUM & PRINCE2

Similar Roles – Different Approach

SCRUM like PRINCE2,  has a set of practices and a set of predefined roles.

PRINCE2: roles, responsibilities and organizational structure

Roles: Executive, Senior user, Senior  Supplier, Project Assurance , Change Authority , Project Support , Project Manager,  Team Manager, Team members.

                        -----------------------------------------------------------------------------------

SCRUM: roles, and organizational structure

Roles:  Product Owner, Scrum Master, Development Team, Stakeholders , Business Owner

----------------------------------------------------------------------------------------------------------------------

Another thing to keep in mind is that PRINCE2 is a process-driven project management method and SCRUM is a reactive / adaptive method.

PRINCE2 and Agile: Are these methodologies compatible?

They are quite compatible. PRINCE2 is a generic Project Management Methodology, while Agile Methods are tailored to suit software application development projects. The question as to how they are compatible requires knowledge of both methodologies.