T-shirt sizes and story points

 In the previous blogs, you learned about T-shirt sizes and story points—the two most common units used to help teams estimate user stories in Agile projects. In this reading, we will explore the processes of estimating user stories in these units. 

As a recap, relative estimation means to compare the effort estimated for completing a backlog item to the effort estimated for another backlog item. Doing this instead of trying to determine exactly how long a task will take allows your comparisons and estimates to be more accurate relative to one another.

T-shirt sizes

At first, T-shirt sizes may seem like a somewhat unusual way to measure an item or user story. But when you think about assigning estimations to items based on sizes (e.g., XS, S, M, L, XL, XXL), it is actually very helpful and easy. Some of the benefits to using this technique are that it is quick, well understood by Agile experts, and a good introduction for teams who are just learning relative estimation.

So what does the process of assigning T-shirt sizes entail? There are several specific techniques a team can try, but each generally follows these steps. The team: 

• Agrees on the chosen scale and metrics to be used.

• Identifies at least one anchor backlog item. That item will be assigned a T-shirt size. Some teams will choose two anchor items—one at the top of the range and one at the bottom of the range.

• Sorts through the remaining backlog items and agrees on T-shirt sizes for each of them. 

Story points

Using story points as the estimate unit is a little more advanced than T-shirt sizes, but it is essentially the same concept. This method is good for experienced teams. When using story points, teams usually use the Fibonacci sequence. As a reminder, this sequence comes from adding the two previous numbers in the sequence together. For example, 1 + 2 = 3 and 2 + 3 = 5. The important thing to notice about this sequence is that, as the list continues on, the numbers spread further apart from each other. Because of this, story points provide more accuracy and specificity than T-shirt sizes. 

So what does the process of assigning story points entail? There are several specific techniques a team can try, but the basic steps are the same as with T-shirt sizes. The team: 

• Agrees on the permitted points values. Some teams cap the size at a certain number, like 21. Some teams decide to jump from 21 to 100 as the next larger value. This is a team decision.

• Identifies at least one anchor backlog item and agrees to assign it a points value. Some teams will choose two anchor items, one at the top of the range and one at the bottom of the range.

• Sorts through the remaining backlog items as a team, agrees on an estimate for each item, and captures it in the backlog management system. 

Best practices

Some best practices, regardless of the technique you use, include:

• Asking the Product Owner questions about the user story or item to ensure that there is enough information to estimate it.

• Discussing divergent estimates from various team members so that everyone has a chance to understand how to implement the item.

• Agreeing on the final T-shirt sizes or points value and capturing it in the system.

• If certain items fall into the larger T-shirt size or story points value range, discussing whether it makes sense to break them down into smaller pieces before moving on.

Key takeaway

Either of these effort estimation units are effective at estimating your items and user stories. As a team, it is important to spend the appropriate amount of time deciding which is best for you. If you are a less experienced team, try starting out with T-shirt sizes, but more advanced teams should feel free to use either method.

Would love to know your thoughts around this topic, please comment below.

Agile effort estimation techniques

 There are all kinds of techniques to use when estimating effort in an Agile way. Effective relative effort estimation leads to successful and predictable sprint outcomes, which leads to a successful project overall. Generally speaking, the main steps to Agile estimation are the same, even if the specific approach varies. Some examples of Agile estimation techniques are: 

• Planning Poker™

• Dot Voting

• The Bucket System

• Large/Uncertain/Small

• Ordering Method

• Affinity Mapping

Planning Poker™

This particular method is well-known and commonly used when Scrum teams have to make effort estimates for a small number of items (under 10). Planning Poker is consensus-based, meaning that everyone has to agree on the number chosen. In this technique, each individual has a deck of cards with numbers from the Fibonacci sequence on them. The Fibonacci sequence is where a number is the sum of the last two numbers (e.g., 0, 1, 2, 3, 5, 8, 13, and so on). 

Sometimes, Planning Poker decks also include cards with coffee cups and question marks on them. The question mark card means that the person doesn’t understand what is being discussed or doesn’t have enough information to draw a conclusion. The coffee cup card means that the person needs a break.

The Planning Poker strategy is used in Sprint Planning meetings. As each Product Backlog item/user story is discussed, each team member lays a card face down on the table. Then, everyone turns their card over at the same time and the team discusses the estimates, particularly when they are far apart from one another. By first hiding the estimates, the group avoids any bias that is presented when numbers are said aloud. Sometimes, when hearing numbers aloud, people react to that estimate or the estimator themselves, and it changes what their initial thought may have been. In Planning Poker, teams can easily avoid that bias.

Dot Voting 

Dot Voting, like Planning Poker, is also good for sprints with a low number of Sprint Backlog items. In Dot Voting, each team member starts with small dot stickers, color-coded by the estimated effort required (e.g., S=green, M=blue, L=orange, XL=red). The items or user stories are written out on pieces of paper placed around a table or put up on the wall. Then, team members walk around the table and add their colored stickers to the items. 

The Bucket System

The Bucket System is helpful for backlogs with many items since it can be done very quickly. In fact, a couple hundred items can be estimated in just one hour with the Bucket System. The Bucket System is an effective strategy for sizing items because it explores each item in terms of pre-determined "buckets" of complexity. Keep in mind that these buckets are metaphorical; this strategy doesn't require the use of actual buckets, and instead uses sticky notes or note cards as buckets.

In this technique, the team starts by setting up a line of note cards down the center of the table, each marked with a number representing a level of effort. Then, the team writes each item or user story on a card. Each person draws and reads a random item,  then places it somewhere along the line of numbered note cards. There is no need to discuss further with the team. If a person draws an item that they do not understand, then they can offer it to someone else to place. Additionally, if a person finds an item that they think does not fit where it was placed, they can discuss it with the team until a consensus about a more accurate placement is reached. Team members should spend no more than 120 seconds on each item.  

Large/Uncertain/Small 

Large/Uncertain/Small is another quick method of rough estimation. It is great for product backlogs that have several similar or comparable items. 

This is the same general idea as the Bucket System, but instead of several buckets, you only use three categories: large, uncertain, and small. Starting with the simpler, more obvious user stories, the team places the items in one of the categories. Then, the team discusses and places more complex items until each is assigned to a category.

Ordering Method

The Ordering Method is ideal for projects with a smaller team and a large number of Product Backlog items. First, a scale is prepared and items are randomly placed ranging from low to high. Then, one at a time, each team member either moves any item one spot lower or higher on the scale or passes their turn. This continues until team members no longer want to move any items. 

Affinity Mapping

Affinity Mapping is useful for teams that have more than 20 items in their Product Backlog. 

A best practice is to conduct this technique using sticky notes placed onto a wall, whiteboard, or table. Each sticky note features a different user story or item. Using sticky notes allows the team to move user stories around in order to group them by similar theme, group, and pattern. The team begins by placing one sticky note on the board. Then, the team takes the next sticky note and discusses whether it is similar to the first item. Based on the team’s assessment, the second sticky note is placed in the first group or into its own group. 

After all of the items are grouped (there should be anywhere from 3–10 groups total), the team gives a name to each group that represents the general theme of the items. Then, the groups are prioritized by importance so that the team knows which items to tackle first. 

Characteristics of effective estimation

Regardless of which technique your team chooses, there are several important characteristics the techniques share that lead to effective estimation:

• Avoids gathering false precision of estimates. In Scrum, assigning rough estimates results in more accuracy across the project. Therefore, if the team focuses on identifying relative estimates—rather than a team having a lengthy debate about whether a task will take seven or 10 days of work—the team saves time and avoids potentially missing deadlines.

• Avoids anchoring bias. Many of these techniques (e.g., Planning Poker) keep the initial estimate private, which allows team members to form an independent opinion on the estimate before sharing their thoughts with the team. This prevents a known phenomenon called anchoring bias, where individuals find themselves compelled to put forth estimates similar to others in the room to avoid embarrassment. 

• Promotes inclusivity. These group estimation techniques not only lead to better estimates but also help the team develop trust and cohesiveness.

• Leads to effort discovery. Estimating in these dynamic ways can help the team uncover strategies to get items completed which might otherwise not have been revealed.

Key takeaway

There are several strategies to enlist when it comes to estimating effort and ordering your Product Backlog. Any one of these techniques are useful. Choosing a particular strategy is just a matter of what your team prefers. 

Would love to know your thoughts around this topic, please comment below.

The components of user stories and epics

User stories are short, simple descriptions of a deliverable told from the perspective of the user. Creating user stories helps the team develop a solution that is always centered around the user’s needs and overall experience. 

Epics are a collection of user stories. Think of the concept of user stories in terms of books or films. A story is one single narrative, while an epic is a set of several related, independent stories. Each story tells a specific chronicle, while an epic gives a high-level view of the overall arc. 

User stories

The driving factor behind every Scrum project is putting the customer first. User stories are a key component of ensuring that customers are satisfied with the product. A team writes a user story from the perspective of the user. Not only do user stories provide insight into what goals the user wants to achieve, but they enable collaboration, inspire creative solutions, and create momentum by giving the team a small win when the stories are developed. 

When writing user stories, you will need to include the following components: 

• User persona. What is your user like? What is their relation to the project? What goals do they have? 

• Definition of Done. This refers to an agreed upon set of items that must be completed before a user story can be considered complete. 

• Tasks. What are the key activities needed to complete the user story?

• Any feedback already provided. If you are adding features to an existing product and you have already received feedback from customers on a past iteration, make sure to consider this feedback.  

I.N.V.E.S.T. 

Recall from the video that your user stories should meet the I.N.V.E.S.T. criteria: 

• Independent: The story’s completion is not dependent on another story.

• Negotiable: There is room for discussion about this item.

• Valuable: Completing the user story has to deliver value. 

• Estimable: The Definition of Done must be clear so that the team can give each user story an estimate. 

• Small: Each user story needs to be able to fit within a planned Sprint.

• Testable: A test can be conducted to check that it meets the criteria.

Let’s imagine you are working on a project for a local library. The library hopes to launch a website so that customers can read reviews before they check out books from the branch. The typical template for a user story looks like this: As a <user role>, I want this <action> so that I can get this <value>. Therefore, an example user story for this situation might read: As an avid reader, I want to be able to read reviews before I check out a book from my local branch so that I know I am getting a book I am interested in.

Epics

An epic’s purpose is to help manage related user stories. In this post, Mike Cohn, the inventor of the term “epic” as it relates to Scrum, describes epic as a “very large user story”—one that could not be delivered within a single iteration and may need to be split into smaller stories. The team should discuss together and reach a shared view of how to write and capture their user stories and epics. Keep in mind, epics are just larger user stories that are there to help organize the project. 

Let’s imagine you are creating user stories and epics based on the previous example. User stories may include customers wanting to read reviews of books on the website or wanting to add books to their cart. These user stories could fall into the “website creation” epic. 

Another user story could be that customers want to walk into the library and easily find the non-fiction section. This would fall under the “organization of the physical space” epic.

So rather than those various user stories appearing in a list together, they are organized into sections, or epics.

Testing 1234

It’s important to note that while the Product Owner can write user stories and epics, a Developer can also write them as long as the Product Owner remains accountable for the Product Backlog item.

Key takeaway

Epics allow you to keep track of large, loosely-defined ideas, while user stories are a much smaller unit of work, inspired directly from the end user or customer. Both user stories and epics help teams ensure they are delivering value to the customer.

Would love to know your thoughts around this topic, please comment below.

Characteristics of a great Scrum Team

I hope you checked out my blog about Scrum roles and responsibilities that make up the Scrum Team. See this article on Scrum.org to learn more about the features of a large Scrum Team.

Would love to know your thoughts around this topic, please comment below.

Understanding Scrum Team roles

Each member of the Scrum Team plays a key role in the success of the project. To help the project reach the finish line, you will need to understand what each of these roles entails. In this study, you will learn how the responsibilities of Scrum Master, Product Owner, and Development Team differ from each other.

The Scrum Master

One important function of the Scrum Master is to help the team understand and follow Scrum theory. Specifically, according to the Scrum guide, “The Scrum Master is responsible for establishing the Scrum as defined in the Scrum guide. They do this by helping everyone understand the theory and practice of Scrum, both within the Scrum Group and the Organization. The Scrum Master is responsible for the performance of the Scrum Team. They do this by empowering the Scrum Group to improve its performance, within the framework of the Scrum. ” The Scrum Master ensures that important meetings do take place, such as the Daily Scrum. In much the same way as a coach knows a game clock, Scrum Master is tasked with ensuring that the meeting is kept within the appropriate time box. Time box Scrum concept refers to the time limit of an event.

Scrum Master works as a Scrum Team coach - they encourage the team to build a product on time. They also support the team by creating a collaborative environment so that project goals are achieved. Scrum Master functions include:

• To train team members in various self-regulation and performance

• Helping the Scrum Team focus on creating Higher Value.

• Facilitating the removal of obstacles to the progress of the Scrum Team

• Ensuring that all Scrum events happen and are beautiful, productive, and stored within the timeline (Scrum concept refers to the limited time period of the event)The role of the Scrum Master is sometimes confused with the role of the project manager. Although the two roles share related skills and qualities, they are very different roles.

Scrum Master vs. project manager 

The role of the Scrum Master is sometimes confused with the role of the project manager. Although the two roles share related skills and qualities, they are very different roles.

The Scrum Master is responsible for helping the team understand Scrum theory and practice. They ensure that Scrum events take place and help the team focus on bringing value by removing obstacles. But unlike a traditional project manager, they do not take change management in scope or priorities. Additionally, Scrum Masters do not retain traditional project artifacts such as GANTT charts.

The Product Owner

According to the Scrum guide, “The Product Owner is responsible for maximizing the product output resulting from the Scrum Group's work. How this is done may be very different from the organizations, Scrum Teams, and individuals. ” Product owners increase product value by representing and articulating customer feedback throughout the project. A product is of no use to its customers if that product does not meet their expectations and meets their needs. Product Owner duties include:

• Promoting and communicating openly the Product Policy

• Creating and explicitly communicating behind-the-scenes products (Product History contains all the features, requirements, and functions associated with delivering to achieve a project goal.)

• Ensuring that Product Backlog is transparent, transparent, and understandable

Product Owner vs. project manager

In normal project management, scope management is the primary responsibility of the project manager. But in Scrum, the definition and management of product scope falls to the product owner. In contrast, the product owner is not responsible for the team's performance — they are not considered management. The project manager leads the project team to meet the project objectives and to direct activities and progress.

There are also similarities between the roles of the product owner and the roles of the project manager. For example, both roles are assigned to the role of stakeholder management. This means that both must practice and facilitate effective communication between team members and participants.

Additionally, for many companies — including Google — product description or solution scope is the responsibility of a different role called product manager. Therefore, it is important when you join any new company to find out how that company reaches the area of ​​product description, product development, and user research to understand what they consider to be the project manager domain.

The Development Team

The Development Team, also called Engineers, is made up of people who do the work of building a product. According to the Scrum guide, the Developers "are members of the Scrum Group who are committed to creating any useful Sprint Climbing feature." Their responsibilities include:

• To create a Sprint program, Sprint Backlog (a set of product backgrounds selected for completion during the next Sprint)

• Adding quality by adhering to the Performance Index

• Getting used to their daily plan is based on the Sprint goal

• Accountability as an expert

• It uses sprints for designing, constructing, and evaluating product backlinks

An important aspect of the Development Team to be highlighted is that it has a variety of functions, which means that you will have expert team members in different fields. In the software team, that may mean having a web developer, a web developer, and an expert in-depth user experience. In a marketing team, that might mean having writers, editors, search engine optimization experts, and business analysts.

The roles working together

Scrum roles are intertwined, and each brings its own unique attributes, skills, and responsibilities together to lead to successful Scrum projects. It is important that everyone in the group understands their role and how they work together to bring value to their users and customers. If the team has this shared understanding, they can better support it during Scrum.

Necessary traits for each role 

All in all, you will be looking for people in your team who are committed to continuous collaboration and improvement. Specifically, it is good to have team members bring feedback, bring strength and fun to the team, and be able to admit and learn from their mistakes. Let's look at what each member of the group should look for:

The Product Owner should be able to confidently provide the team with general guidance, requirements, and objectives of the project but will allow the team to decide how to achieve these goals. Your team will look for a Product Owner who develops a product concept and prioritizes product backlogs to maximize customer value. To achieve this, the Product Owner must be organized and have strong communication skills.

The Scrum Master must have strong leadership skills that enable them to be effective facilitators and negotiators who are able to resolve conflicts. Your team will be looking for a Scrum Master who aims to successfully train the Development Team, event management, and eliminate obstacles that may hinder team progress.

When it comes to Development Team, you will be looking for people who are always focused on completing the delivery and producing a high quality end product. As the team organizes itself and works in a variety of ways, you will want people who are willing to work together and who are not afraid to compromise in order to achieve great product.

Would love to know your thoughts around this topic, please comment below.

The Scrum Guide

The Scrum Guide defines Scrum as “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” This reading will review the Scrum pillars and values and then provide links to the Scrum Guide and further reading about Scrum. 

Pillars and values 

To recap, every person on a Scrum team subscribes to the three pillars and the five values of Scrum. The three pillars of Scrum are: 

• Transparency 

• Inspection

• Adaptation 

The five values of Scrum are: 

• Courage 

• Commitment 

• Focus

• Openness 

• Respect 

In order for a scrum team to succeed, it is incredibly important that every team member follow these core pillars and values.

Scrum only has a few rules and practices that are easy to follow. It is also easy to understand. However, Scrum can be challenging to master because mastery depends on being able to embody, live, and promote the pillars and values of Scrum. 

Helpful links 

Take a deeper look at the framework in the Scrum Guide. For further reading about Scrum, check out Scrum.org. 

Would love to know your thoughts around this topic, please comment below.

Avoiding ethical traps in procurement

Let’s talk about some potential ethical traps you might face and how to navigate them. 

Understanding ethical traps 

An ethical trap is an ethical dilemma that causes us to make a certain decision without regard for our ethical principles. You may face ethical traps throughout the course of a project. However, ethics can be of particular concern when it comes to procurement. As you have learned, project managers must take precautions to ensure that they and their suppliers are following ethical principles during the procurement process. 

Common ethical traps

Sometimes, potential ethical issues can be overlooked or can be considered the necessary cost of doing business. This is a dangerous line of thinking since these types of assumptions can put your project, company, and career at risk. To review what we discussed in the video, a few of the most common ethical traps that exist when conducting procurements are corruption and bribery, sole-supplier sourcing, and interactions with state-owned agencies.

Corruption and bribery   

You may be confronted with different types of corruption when going through the procurement process. One form of corruption is when a vendor seeks to reduce the competition for a contract during the bidding process. A company may attempt to bribe members within the organization to sway their decision into a favorable outcome for the vendor. Bribes may include things like money, gifts, tickets to events, and more. Another type of corruption scheme is to offer a certain percentage of an awarded contract—also known as a kickback—to an official who can ensure that their company wins the bid.

Sole-supplier sourcing   

In some situations, having a vendor who a company is already familiar with smooths the procurement process and works well for both parties. Ethical issues arise when other vendors aren’t even allowed to bid for contracts for which they are similarly qualified. With sole-supplier sourcing, vendors may reach out to buyers before a bid is even requested. When the buyer’s organization decides to work with that vendor based on their previously-established relationship, that limits competition before the bidding has even begun. When this happens, companies and the public miss out on the advantages of competition, such as reasonable pricing, product quality standards, or speedy delivery options. 

Interactions with state-owned entities

There are some instances in which government agencies require an organization to adhere to stricter ethical standards than they might have otherwise. Most government regulatory agencies exist because a company or an entire industry has ranked profits over their workers or the environment. Governmental agencies such as the Food and Drug Administration and The Occupational Safety and Health Administration, for example, keep businesses within legal and ethical standards. If you are unfamiliar with any governmental restrictions that may affect your industry, organization, or project, you could unintentionally fall into an ethical trap.

Avoiding ethical traps   

Here are some guidelines that will help you avoid falling into ethical traps when it comes to procurement:

Understand the legal requirements for your procurements.

Every country has regulations to adhere to when conducting business in that country. Be sure to research the legal and ethical requirements based on your project and procurement needs, and if your organization has a legal team, make sure to lean on them for support and advice.

Stick to your ethical codes.

Honesty, responsibility, respect, and fairness are the values that underpin ethical behavior in the project management profession. The Project Management Institute’s (PMI) code of ethics provides detailed guidelines to help ensure you maintain ethical conduct in your projects. 

Test your ethics.

When you face an ethical dilemma, ask yourself questions in each of the following categories:

• Shame: Would you be ashamed if someone knew what you did?

• Community: Would you want your friends to know the decision you made? 

• Legal: Would you face legal action if you took this action? 

• Situation: Would your actions be justified in this situation?

• Consequence: Would a negative outcome be worth your actions? 

Key takeaway

Making a decision when facing an ethical dilemma can be challenging. But learning the legal requirements for your procurements, sticking to a professional code of ethics, and testing yourself on the ethics of your decision making can help you avoid ethical traps and conduct your procurements honestly, responsibly, and fairly.

Would love to know your thoughts around this topic, please comment below.

Introduction to Kanban boards

 Kanban boards are a visual tool used to manage tasks and workflows. Kanban boards can be created on whiteboards, magnetic boards, poster boards, computer programs, and more. Tasks associated with the project are written on cards. These cards are placed in columns, which represent the progress made. 

Although Kanban boards are useful for all kinds of projects, they are typically most suitable for project teams working in an Agile project management approach. You may remember that Agile project management is an iterative approach to managing projects that focuses on continuous releases and incorporates customer feedback with every iteration. Once you become a project manager and have created your project plan, you can decide whether a Kanban board is right for your project. 

Purposes of a Kanban board

Kanban boards are used to:

• Give a quick visual understanding of work details and provide critical task information.

• Facilitate handoffs between stakeholders, such as between development and testing resources or between team members who work on related tasks.

• Help with capturing metrics and improving workflows.

Using a Kanban board

Before creating a board, it is best practice to gather the necessary information and lay out key elements, such as tasks, status, dates, and durations. That information is useful when building your board. 

Let’s turn our focus to an example of a Kanban board below. Each colored rectangle is associated with a task. The tasks are represented horizontally across the effort timeline. Each column represents where the task is in relation to its completion. So as a task is started, it will move from to do, to in progress. When the project is almost ready to be released or complete, it will move to testing, and when it is tested and approved, it will move to done. Note that this is just one example of a Kanban board, and depending on the tool you use—such as software or a physical board—you can customize your board using various columns and cards. The board can also have rows for resources (team or person), to help visualize who is actively working on what.

Creating cards

Cards will vary in style—you can even use sticky notes on a whiteboard—but most cards will contain a few key details about the task that they represent. When using physical cards, teams often use both sides. Here is what both sides of the card should include:

Front

• Title and unique identifier: Make sure you have a quick reference for tasks and ID numbers.

• Description of work: Briefly describe the task to be accomplished. Remember that this is intended to be captured on something no larger than an index card.

• Estimation of effort: Estimate the amount of work it will take to complete the task. For example, you can write “small,” “medium,” or “large” to indicate the level of effort you think that task will involve. 

• Who is assigned to the task: Indicate who is responsible for completing the task; ideally, one person per card.

Back 

• Start date: Include the start date of the task for use in metrics, tracking, and ensuring that your time estimate is accurate.

• Blocked days: Indicate which days your task may be halted. A task can become blocked if it can’t continue to be worked on. For example, if you were supposed to receive a deliverable and it hasn’t been delivered yet, then your day may be blocked for this particular task.

• Finish date: As with any plan, it is important to track when the task is supposed to be finished. This allows you to ensure that your project is still on track to reach the end goal.

Kanban board software

If you opt to use a software tool rather than a physical board, you have a few options. Asana and Trello are both great software tools to use if you are looking to introduce Kanban to your project. There are many options, so take the time to evaluate which is best for you and your project.

Would love to know your thoughts around this topic, please comment below.