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. 

What Is DevOps?

DevOps (a clipped compound of development and operations) is a term used to refer to a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably

Where Did DevOps Come From?

DevOps is the offspring of agile software development – born from the need to keep up with the increased software velocity and throughput agile methods have achieved. Advancements in agile culture and methods over the last decade exposed the need for a more holistic approach to the end-to-end software delivery lifecycle.

The DevOps ideals extend agile development practices by further streamlining the movement of software change thru the build, validate, and deploy and delivery stages, while empowering cross-functional teams with full ownership of software applications – from design thru production support.

DevOps is an IT mindset that encourages communication, collaboration, integration and automation among software developers and IT operations in order to improve the speed and quality of delivering software.

DevOps teams focus on standardizing development environments and automating delivery processes to improve delivery predictability, efficiency, security and maintainability. The DevOps ideals provide developers more control of the production environment and a better understanding of the production infrastructure. DevOps encourages empowering teams with the autonomy to build, validate, deliver and support their own applications. With DevOps, nothing gets “thrown over the wall.”

What Are the Challenges DevOps Solves ?

Prior to DevOps application development, teams were in charge of gathering business requirements for a software program and writing code. Then a separate QA team tests the program in an isolated development environment, if requirements were met, and releases the code for operations to deploy. The deployment teams are further fragmented into siloed groups like networking and database. Each time a software program is “thrown over the wall” to an independent team it adds bottlenecks.

The problem with this paradigm is that when the teams work separately:

• Dev is often unaware of QA and Ops roadblocks that prevent the program from working as anticipated.
• QA and Ops are typically working across many features and have little context of the business purpose and value of the software.
• Each group has opposing goals that can lead to inefficiency and finger pointing when something goes wrong.

DevOps addresses these challenges by establishing collaborative cross-functional teams that share responsibility for maintaining the system that runs the software and preparing the software to run on that system with increased quality feedback and automation issues.

What Is the Goal of DevOps?

Improve collaboration between all stakeholders from planning through delivery and automation of the delivery process in order to:

• Improve deployment frequency
• Achieve faster time to market
• Lower failure rate of new releases
• Shorten lead time between fixes
• Improve mean time to recovery

What Tools Are Used in DevOps?

Earlier we briefly discussed some of the tools used in DevOps; here are some of the key tools and practices you need to know.

Source Code Repository
A source code repository is a place where developers check in and change code. The source code repository manages the various versions of code that are checked in, so developers don’t write over each other’s work.

Source control has probably been around for forty years, but it’s a major component of continuous integration. Popular source code repository tools are Git, Subversion, Cloudforce, Bitbucket and TFS.

Build Server
The build server is an automation tool that compiles the code in the source code repository into executable code base. Popular tools are Jenkins, SonarQube and Artifactory.

Configuration Management
Configuration management defines the configuration of a server or an environment. Popular configuration management tools are Puppet and Chef.

Virtual Infrastructure
Amazon Web Services and Microsoft Azure are examples of virtual infrastructures. Virtual infrastructures are provided by cloud vendors that sell infrastructure or platform as a service (PaaS). These infrastructures have APIs to allow you to programmatically create new machines with configuration management tools such as Puppet and Chef.

There are also private clouds. For example, VMware has vCloud. Private virtual infrastructures enable you to run a cloud on top of the hardware in your data center.

Virtual infrastructures combined with automation tools to empower organizations practicing DevOps with the ability to configure a server without any fingers on the keyboard. If you want to test your brand-new code, you can automatically send it to your cloud infrastructure, build the environment and then run all of the tests without human intervention.

Test Automation
Test automation has been around for a long time. DevOps testing focuses on automated testing within your build pipeline to ensure that by the time that you have a deployable build, you are confident it is ready to be deployed. You can’t get to the point of continuous delivery where you’re fairly confident without any human intervention that your code is deployable without an extensive automated testing strategy. Popular tools are Selenium and Water.

Pipeline Orchestration
A pipeline is like a manufacturing assembly line that happens from the time a developer says, “I think I’m done,” all the way to the time that the code gets deployed in the production or a late-stage pre-production environment.

Unifying Enterprise Software Development and Delivery
The VersionOne Enterprise Agile Platform unifies agile application lifecycle management and DevOps, providing a full picture of your entire software delivery pipeline in a single platform. VersionOne® Continuum™ for DevOps is an enterprise continuous delivery solution for automating, orchestrating, and visualizing the flow of change throughout the software delivery cycle.

The conflicts and complaints wall