DEV Community: Rebecca Ferrao

Minimum Marketable Feature in Agile - What is it?

Rebecca Ferrao — Tue, 21 Dec 2021 12:53:19 +0000

What is 'Minimum Marketable Feature'?

Minimum marketable feature (MMF) is a small feature which is delivered fast and gives significant value to the user. The term, MMF, isn't very widely used. However, the first agile principle and the MMF are in alignment.

The first agile principle states that the highest priority of the agile team is to satisfy the user. This is through early and continuous delivery of valuable software to the customer.

Both the first agile principle as well as MMF talk about delivering value to the customer. They try to give value that the customer hadn't had before, even if this is done frequently. The term 'marketable' defines this.

Now, value can have a lot of definitions based on where you're looking. It could increase the revenue of the company or reduce customer cost. So, the MMF concept applies to both internal and external products. Products used within an organization as well as ones which are sold outside can make use of MMF.

Origin

As we have mentioned above, the MMF concept isn't much used. However, it's been around for a few years now. Mark Denne Dr. JaneCleland-Huang wrote about the concept in 2004. Their 2004 book, Software by Numbers: Low-Risk, High-Return Development, spoke about MMF for the first time. The concept has been in use since.

MMF vs MVP

You may know of the concept of theMinimum Viable Product (MVP) and wondering if the MVP and MMF differ in any way. Well, they are different in practice. Let's understand the difference here.

The MVP

Firstly, let's look at the definition of the MVP as defined by Eric Reiss in the Lean Startup methodology. The Minimum Viable Product is a version of a new product which requires the least effort but allows maximum learning. This learning is in the form of customer feedback, when the MVP is adopted by early customers of the product.

The MVP tries to check whether the team is building the right thing in the first place. For this sake, they try to use a minimum amount of time and money when making it. The early adopters then give valuable feedback about their experience with the MVP. This allows the team to determine if it's worth going ahead and building the complete product.

MVPs need not necessarily be a product. Anything which explains to the user what the product would do can also be considered as an MVP. For example, Dropbox only made a video to show their customers what they could expect out of the end product. Only after they saw that there was demand did they put in effort into creating it.

The MMF

Now, we've already defined an MMF at the start of this blog. The exact textbook definition, as given in 'Software by Numbers', is

'"The Minimum Marketable Feature is the smallest unit of functionality with intrinsic market value.'

It is a real feature, which solves the customer's need in some way. The MMF can be marketed and sold. It's all about releasing products that have a high value, and doing so fast. Building an initial product with the main features and later making incremental, high value changes is an example of an MMF.

Minimum Marketable Feature vs Minimum Viable Product

So, from the above two you can see that while the MVP focuses on learning, the MMF's focus is on providing value to the user.

The MVP may or may not have an MMF, or it could have more than one MMF built into it. Your use of either concept would depend on your context and need.

The MMP - Minimum Marketable Product

So now you know about the MMF and the MVP. However, there's yet another term, the MMP, which may lead to some confusion. Let's understand what the Minimum Marketable Product is.

After the MVP, the MMP can be considered as the next practical step in the product building process. The MMP is the very core version of the product which has just the basic features needed by it. In other words, only the 'must-have' functionalities are incorporated into the MMP. The 'good-to-haves' aren't added in this stage.

Like the MMF, the MMP tries to market a product at a fast pace and with the necessary features. The MMF, focusing on a feature, then becomes a subset of the MMF.

Example of Minimum Marketable Feature

After an initial product with some solid, core features has been released, there may be a progressive addition of new features. One very stark example is the operating systems of cell phones or computers. The smartphone would of course work right out of the box. But, over the course of using it, users would see that there are more updates added regularly. These are features that add value to the product, but aren't required at the very start. Hence, they can be added incrementally.

Originally published here.

Also check out:

Understanding the basics of Story Grooming

Rebecca Ferrao — Mon, 13 Dec 2021 12:26:56 +0000

What is Agile Backlog Grooming?

Backlog grooming is an agile product team event to make sure that the backlog is sufficient. In essence, the product team ensures that there are enough user stories in the product backlog which are prepared for spring planning. Backlog grooming is also known as backlog refinement, or backlog management, or story grooming, or story time. These events, or sessions, are recurring in nature.

Having backlog grooming sessions regularly helps to make sure that the team prioritizes the right stories. This way, the team has a good grasp over the complete product backlog. In these backlog refinement sessions, the product owners or managers explain the purpose of the prioritized stories to the team. The team is then in a position to be better aligned about the project purpose.

The things that the backlog grooming session tries to achieve are as follows:

Refining the leftover user stories and removing the ones which are no longer relevant.
Adding new stories based on the needs that are newly discovered.
Breaking bigger items into smaller, easier tasks, orsplitting user stories.
Prioritizing the ones which are to be tackled first.
Discuss the user stories with the team and answer any questions which arise so that there are no doubts
Add contextual info and acceptance criteria to the upcoming user stories
Occasionally, the scrum master estimates the user stories and assigns story points in these sessions.
Corrections to the existing estimates based on the new info available.

All these items together work in shaping up the tasks and objectives for the next session. The key team stakeholders attend these backlog grooming sessions. To keep the sessions running well, too many people aren't a part of the meetings. However, all the important stakeholders are supposed to be a part of it. These include the core team representatives, product managers, owners, and QA, among others.

Origins of Story Grooming

Now that you know what Story grooming is, let's understand how the practice came into being.

The earliest known use of the term, 'backlog grooming' was on a Yahoo group in 2005. In that year, Mike Cohn, one of the well-known contributors of the scrum world, spoke of it on Yahoo. Specifically, this happened in the Yahoo Group, Scrum Development Mailing List. However, at this time the term wasn't well-defined and didn't come into use.

A few years later, in 2008, Kane Mar, a scrum trainer, gave one of the first formal descriptions of the term. He called it 'story time' and recommended that these should be implemented as regular meetings in Scrum teams.

Three years after this, in 2011, Backlog grooming became a part of the Scrum guide. Since then, it's been recognized as an official element of the agile scrum framework.

Who is a part of the Story Grooming sessions?

We've already mentioned in passing who is a part of these sessions above. However, let's understand the details here.

Who leads Backlog Grooming sessions?

Usually, the product owner or product manager facilitates the backlog refinement events. It's not limited to them, though, and the Scrum master, a project manager or another member from the team also occasionally leads the events.

Whoever leads the sessions has to assume the following responsibilities:

Schedule the meeting and invite the right people, also make sure that they attend.
Ensure that the team doesn't go off topic and is focused on the objectives.
In case the team is stuck too long on a particular topic, then moving the conversation forward.
Communicating to the team after the session is over about the necessary things.

Generally, these sessions take about 45 minutes to an hour. So, the lead has to also try to ensure that the meetings don't take too much time. They have to try to keep it short and efficient.

Who attends the Backlog Refinement sessions?

The story grooming sessions are collaborative discussions. For this, it is necessary to get inputs from various team members and to look at things from all viewpoints. At the same time, it's necessary to not overcrowd the meeting and invite only the critical members.

So, on a broad scale, these are the roles that attend the backlog grooming sessions:

The facilitator or the lead as mentioned in the earlier section.
The product owner and/ or other representatives of the product team.
The entire delivery team or key representatives if it's too large.
QA reps.

Preparation for efficient Story Grooming

The following is an idea on how to prepare for the agile story grooming sessions and what to include in them:

1. Keep the strategic objectives of the project in mind

At any point of the project, the ones working on it should keep in mind what the main goals of the project are. So, even when preparing for the grooming sessions, the high-level objectives of the project should be kept in mind. Everything should then be aligned accordingly.

2. Involve the right people in the process

We've mentioned above who the ideal people in the story grooming process are. You need to decide who are the best people to invite if you're the one conducting the meeting.

3. Sync up with stakeholders

Talk to internal and external stakeholders at regular intervals to get feedback. You do not need to invite them to the grooming sessions, but make sure to keep them updated.

4. Review work done and metrics

Since your team's working style could evolve over time, it's good to get an idea of what to keep and what to discard. Tracking and reviewing performance metrics helps with this.

Best practices for Story Grooming

The story grooming sessions aim to have a prioritized set of user stories for the team to work on. Agile practitioners usually try to obtain a 'DEEP' product backlog as a result of these sessions. This is what DEEP stands for:

D - Detailed Appropriately - Items should be stated in very clear terms so that the team and everyone involved have no issues in understanding.

E - Estimated - Teams should draw a good estimate of the work needed to deliver backlog items which are at the top.

E - Emergent - The agenda isn't concrete and changes over time. So, it should be easy to accommodate these changes.

P - Prioritized - Items are ranked according to their value and then taken up in order.

Originally published here.

P.S. If you liked the above, also check out the following:

LeSS Agile Framework - Your guide

Rebecca Ferrao — Mon, 06 Dec 2021 08:38:47 +0000

What is the LeSS Agile Framework?

The LeSS Agile Framework is a scaled-up type of the usual one-team Scrum framework. It is a method for scaling scrum for many teams working together on one product. The abbreviation, LeSS stands for Large Scale Scrum.

This framework tries to use the principles of scrum in a large-scale firm easily using defined rules. It's quite a simple framework and is often looked at as 'barely sufficient.

The Scrum framework as we know it splits work into teams and each teamwork on a few projects at a time. This is done in sprints, where each sprint consists of a few increments. The method is ideal for small teams. However, the LeSS framework tries to scale this to a larger group of teams working on the same product. There are some other frameworks which also aim to do the same.

Origins

Well known agile authors, Jeff Sutherland and Ken Schwaber defined the working of a single scrum team in the Scrum Guide. In 2005, Craig Larman and Bas Vodde further refined this technique to apply to larger teams. While working at Nokia Siemens Networks, where a very large number of people were working on the same product, they came up with the LeSS framework.

The framework was meant to deliver value as well as reduce complexity and waste in the process. Since its inception, the LeSS framework is often used when there's more than one team working on a product.

Principles of the LeSS Agile Framework

LeSS agile framework has 10 principles defined as follows:

Large-Scale Scrum is Scrum The Scrum process itself is scaled in LeSS, without adding extra artifacts.
Systems Thinking Everyone across the organization thinks about what is happening, not just the makers. Decision makers can avoid mistakes by using this.
More with LeSS The structure is simpler. Now, the focus is on responsibility and ownership instead of roles and processes.
Lean Thinking There isan effort to remove all the waste in the process and keep only necessary components.
Transparency When everything is clear, it is easier to address and solve issues.
Empirical Process Control LeSS encourages you to create features fast and adapt it as necessary based on feedback.
Customer Centric Even after scaling, the customer's needs are the focus.
Continuous improvement towards perfection This shows that it's okay to not be perfect from the get-go but always strive to get there. It also encourages one to keep in mind that there can always be something better.
Queueing theory Queueing theory aims to eliminate queues and effectively manage the ones which can't be eliminated. For example, the product and sprint backlogs are queues. Only necessary components are to be kept.
Whole Product Focus Each team is to keep the whole product in focus when working. They are not to focus on just their component and ignore the rest of it.

Roles and Responsibilities in LeSS

In LeSS, you do not find product or program managers. Instead, these responsibilities are given to Product Owners and the feature teams. These Feature teams work on the development, and are comparable to product teams.

The members of the feature teams work together and create end-to-end customer-centric features. They do not just work on some components or layers. The members of the team are self-managing and cross-functional. A Scrum master looks over the feature team, and can look over up to 3 teams. The Product Owner and Product backlog are common across all feature teams.

In the LeSS agile framework, the Product Owner and Feature teams are actually peers. The Product Owner connects the team to the customers. However, they don't have to be an intermediary in the process and focus more on customer discovery.

Two LeSS frameworks - LeSS Huge vs Basic LeSS

The LeSS agile framework has two ways of working. First, the Basic LeSS configuration for two to eight teams (usually 10-50 people). The second is for more than eight teams (50-6000+ people usually). LeSS Huge works on the same basic principles of Basic LeSS we've described above.

However, in LeSS Huge, the role of the 'Area Product Owner' is added. The Area Product Owner/ APO focuses on a single requirement area. There could be two or more of these APOs and along with the main Product Owner, they make up the Product Owner Team. There could also be additional Project Managers based on size and need.

Differences between the LeSS agile framework and traditional Scrum

Large Scale Scrum, LeSS, is a scaled-up form of the traditional Scrum method. But, there are some differences between the two. For instance,

In traditional Scrum, each team has a backlog based on its own responsibilities. But in LeSS, there's one common Product Backlog. All teams then work on a common sprint, with their focus on the product.
'Done' is defined in the same way across the product group rather than each team having its own definition.
The process includes an overall retrospective unlike the agile retrospective in one-team scrum.

Originally published here.

P.S. If you liked the above, also check these out!

Splitting User Stories - What it is and techniques used

Rebecca Ferrao — Fri, 26 Nov 2021 07:09:07 +0000

What is a user story?

Firstly, let's understand what stories are in agile. It is a short description that talks about the desired function from the perspective of the user. Agile teams size these in such a way that they can be completed in one iteration. These are the basic artifacts that eventually define the system behavior. Both business as well as tech stakeholders can understand the story's intent with ease.

They are of two types: User stories and Enabler stories. The former delivers the functionality to the final user. The latter on the other hand brings more visibility into the building process. In this blog, we will be dealing with user stories, and splitting user stories.

To understand the difference between the two types of stories, let's take this example:

User story (end user): As a commuter, I want to identify the nearest cab I can book so that I can travel to my destination faster.

Enabler story: Use the device GPS and sync with nearby registered device GPS.

In agile, user stories are the most basic means of telling what is the needed functionality. They focus on the end user and are very customer-centric in nature. The subject of interest in a user story isn't the system, but rather the user. User stories also define the business value of the requirement at hand.

So, roughly, a user story would be written combining the following:

User Story = User role + Activity + Business Value.

In the above example, the user role is that of the commuter.

Activity is identifying the nearest cab.

The business value would then be the need to travel faster to the destination.

Through this method of writing user stories, the dev teams understand these things:

Who would be using the product/ who they are building for
What the user is doing with the feature
Why are they building the product?

Now that we know what user stories are, let's move on to understanding splitting user stories.

What does 'Splitting user stories' mean?

When a user story is ready so that it can be scheduled for implementation, it should be 'small enough'. What this means is that the story should be such that the developers can complete it in one iteration. This is a general rule of thumb around user stories.

The agileINVEST acronym states the characteristics of a good user story and can be cited here. A quick refresher, this is what the acronym stands for:

I - Independent

N - Negotiable

V - Valuable

E - Estimable

S - Small

T - Testable

As is clear, the S-Small suggests that user stories are to be small in size. These allow faster implementation, and are also more reliable. This is because being small in size, they flow through the system with a less amount of risk and variability.

However, it so happens that most user stories are complex in nature. They cannot be completed in one iteration.

This is where user story splitting comes into play. As you might have already figured, splitting user stories means to split a bigger, more complex user story into a smaller one to complete it in one go. This process is also known as story splitting. Since a user story has three parts, the role + activity + business value, it's a must to keep these on splitting. So, story splitting is done such that each story has a measurable business value by itself.

But, how is this done? Well, there is no one way for splitting user stories. The ways of doing this depend on the business domain and hence various authors have their own ideas on how to do it. In the coming sections we will touch upon some of the ways of splitting user stories.

Agile Techniques for Splitting User Stories

These are some of the common ways of splitting user stories:

1. Story splitting by capabilities offered

In this, you have to look at the capabilities being offered by each user story. For example, if a main user story needs you to search as well as sort, you can split these into two. You can also then further split these if you have multiple ways of sorting and searching in each.

2. Based on the devices the app is to be used on

You can't expect all the users using your software to use it on the exact same type of system. For this, you have to make accommodations for devices, settings, and other things. So, you can split user stories based on these differences and work on one at a time.

3. Splitting based on user roles

Note that the same software would be used differently by different users. For example, consider a recruitment portal. The users would be using it in a different way than the HR managers. Same thing for educational software, teachers and students wouldn't be using it in the same way. Thus, you can define the different roles of people who would use the system. Through this, you can also split the features and work on them accordingly. In this way, it's easier to address the varied needs of each user.

4. Splitting user stories based on user personas

Again, after user roles, user personas also could differ. This would depend on a number of things. For example, if a person has a lot of knowledge about the system, they'd want shortcuts so that they can work faster. A newer user would need a lot of guidance on the system and you'd probably have to integrate a lot of tips or guides. Someone with a physical handicap would need to interact with the feature in a different way.

Based on such differences in personas, you can split your user stories so that you are focusing on only one at a time.

5. Split user stories by workflows

One main feature can be divided into a number of smaller ones. Take, for instance, posting a photo on an app like Instagram. You'd first choose the picture from your gallery, or click one. Then, you might want to make some edits to the picture. Next, tagging people and adding a location and caption would come into play. After all these things only would you post the picture.

Of course, the example we've taken is bound to be more complex than this, but the basic idea is to split based on the flow. So each of these tasks can be worked on as a separate user story.

6. Split based on data types

Here, we shall consider local ways of entering data all over the world. Suppose you are creating an app to track the amount of steps you take a day and the distance covered. In the USA, you'd have to show this data in miles. But, in India, you'd have to show the same data in kilometres. So, when making an app, you'd come across different ways of entering data. You can split user stories based on the data types accordingly.

7. Splitting user stories by the CRUD operations.

As you might know, CRUD stands for Create, Read, Update and Delete. You can split your user stories into smaller ones based on this. This way, a smaller user story would involve only dealing with the Creation of something. Another might deal only with the way users Read certain data.

The SPIDR method for splitting user stories

The SPIDR method is a relatively new way of splitting user stories. It stands for:

S - Spikes

P - Paths

I - Interface

D - Data

R - Rules

Let's understand how it works.

Spikes
Spike is a method to make the development team more aware of the things they are doing. Technical unknowns tend to make a story large, so the team needs to learn before making user stories. Only after understanding the components in detail do they work on writing and splitting the user stories.
Paths
There could be multiple ways of carrying out a function. Say to pay online, you could use credit or debit card or some other way. User stories are then made to tackle each of these.
Interfaces
This is similar to the point about devices mentioned earlier. You can split user stories based on the devices and interfaces users will be interacting through.
Data
The data would be entered in different ways. Take for instance filling a form. Here, you could work on one story for collecting and storing basic user data such as name and location. Another story could then collect the picture.
Rules
User stories would have some restrictions to make it function well. So, you can split and add just one rule at a time in each user story. For example, the first user story would be open and have no restrictions and collect any sort of data. The next ones can add various restrictions on this data.

Originally published here.

P.S. If you liked the above article, also check out the following:

Sprint Velocity - Your guide

Rebecca Ferrao — Fri, 19 Nov 2021 12:32:17 +0000

What is Velocity in Scrum?

Velocity is the amount of work a scrum team can accomplish during a single sprint. In other words, it is the amount of product backlog that the team turns into an increment of the end product in a given sprint. Velocity is a vital metric to know the rate at which the scrum team can deliver valuable products. The value is calculated after the sprint is over, by taking a total of the points for all completed user stories.

Making use of the velocity, the team can determine how long the project will take to complete. Based on this, they can accordingly revise the time for release if required. This determination takes into consideration the estimate for the remaining user stories. It also assumes that the velocity of the scrum team over the remaining iterations will be the same.

So we know the very basics of it, but let's understand the velocity in scrum in more detail. Read on to find out how it came into use and how it's calculated.

History

Velocity in Scrum is a concept whose exact origins are tough to trace. The concept came into being over a period of time and going back to the exact point isn't possible.

Some early works, such as 'Planning Extreme Programming' (yr: 2000) had mentions of Individual Velocity. Earlier, 'Ideal weeks' used to be estimated, but this was soon replaced by Story points. Instead of the number of weeks the project should ideally take, it was now the effort required that was considered.

In the 2000 book however, Velocity came into use as a replacement to the earlier term 'Load Factor'. A couple years later, in the year 2002, the Scrum users adopted the practice of measuring velocity.

Scrum Velocity Calculation and Example

To get an idea of the amount of work that the team will be able to complete, it is necessary to know the past performance. You can review the past three or so sprints to get a good idea of the average work that the team is capable of.

We have made use of story points in this example to calculate the work completed in each sprint. A quick reminder that story points is a measure of effort and time that a user story is expected to take. We've given more details about story point estimation using the Fibonacci series here. The following is a brief on how you can measure the performance. Consider the work over three sprints:

Sprint 1:

In this sprint, the team has agreed to complete six user stories.

Next, each user story has seven story points.

This means that the total number of story points in the sprint is 42.

At the end of the sprint, the team has completed five out of six user stories.

Sprint 2:

Here, the team has agreed upon seven user stories including one from the earlier sprint.

Again, the number of story points is seven, in this case, amounting to a total number of story points of 49.

By the end of this sprint, the team has completed five user stories.

Sprint 3:

In the third sprint, the team commits to working on eight user stories. This again includes two user stories from the earlier sprint.

The number of story points is the same as the other two, seven in each. As can be seen, the total number of story points is 56.

The team completes six user stories in total in this sprint.

Now that we have the data of three sprints, the next step is to calculate the average of the three sprints.

The average number of story points completed = Sum of story points completed in each sprint / Total number of sprints.

Story points completed in each sprint:

1 and 2 = 5 user stories * 7 story points = 35

3 = 6 user stories * 7 story points = 42

Therefore, the average number of story points is then calculated to be

(35 + 35 + 42)/3

=~37

Hence, this 37 is our average sprint velocity. The rest of the work is calculated based on this. For instance, if the team has to complete 220 more story points, dividing by 37 will give us a good estimate.

So, 22/37 = ~6

Thus the team would need around 6 more sprints to complete all the user stories. This is under the assumption that each sprint includes about 37 story points. Note that this is an approximation and there could be changes from one sprint to another. Hence, velocity in scrum can't be considered as an exact value.

Velocity Chart

Teams make use of the velocity chart to visually track the progress of the work that they have done. The sprint burndown chart is also made use of for this purpose.

The velocity chart is a graph of estimated story points against completed story points. It is a simple double bar graph which shows how many story points were committed to and how many were done.

The burndown chart shows how much work is complete, what's left and the amount of time remaining for the same.

Originally published here.

P.S. If you liked the above blog also check out the following:

Scrum of Scrums - Your guide

Rebecca Ferrao — Mon, 15 Nov 2021 12:32:14 +0000

What is Scrum of Scrums?

A Scrum of Scrums, also known as Meta-Scrum, is a scaled agile technique used to connect multiple Scrum teams who work together on a complex solution.

Having a higher number of members in a single team increases the lines of communication. Due to this, smaller Scrum team sizes are recommended. So, when working on complex projects, the large group team is split into smaller Scrum teams. This helps to reduce lines of collaboration and maintain personal collaboration. These teams have their daily standups to discuss the tasks for the day. In these, they choose an 'ambassador' to participate in the Scrum of Scrums. The Scrum of Scrums is hence a meeting of ambassadors from the smaller Scrum teams.

These ambassadors may be a technical contributor, Scrum master, a product owner or a manager. Teams usually alternate their representatives over the course of the project.

In the Scrum of Scrums, a rep from each Scrum team shares major updates on the team's work. The rep talks about the team's progress and challenges faced. This usually happens after the daily standups, so that they convey the latest info.

The meeting is a way to enable teams to have effective cross team collaboration. It promotes transparency and adaptation at scale when working on a complex project. Teams highlight dependencies and tackle integration and conflict points. This technique is the oldest and most commonly used agile scaling framework.

History of Scrum of Scrums

Jeff Sutherland and Ken Schwaber, two of the pioneers of Scrum, first used the Scrum of Scrums method in 1996. It arose from a need they both had, to coordinate eight business units. Each of these had multiple product lines. Due to this, an effective way to bring about sync between the members was needed. To tackle this, the Scrum of Scrums came into being.

Inspired by this instance, Jeff wrote about it publicly for the first time in 1996. The article, 'Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies' brought popularity to the Scrum of Scrums. This method has since been in use all over the world.

The Structure of Scrum of Scrums

The below diagram gives a visual representation of the structure.

Consider that the people working on the project are about 35 in number, split into 5 Scrum teams of 7 members each.

Now, these teams have their daily Scrum meetings/ standups. One member then represents the team in a Scrum of Scrums. This is shown in the top row

If needed, on bigger projects, teams also make use of Scrum of Scrum of Scrums. This, as the logic follows, would be reps chosen from multiple teams of reps. Each of these teams would actually be a Scrum of Scrums.

Conduction of Scrum of Scrums

Agenda

When the Scrum of Scrums takes place, the team reps answer the following questions:

What was the work done by the team since the last meeting?
What work will the team do before the next meeting?
Is your team facing any impediment which is slowing its work?
Does your team's work have the chance of obstructing any other team's work in any way?
Is the work of any other team obstructing your work?

The exact questions could differ a bit, but these sum up the general agenda of the meeting.

Participants

As already stated earlier, the team rep or ambassador is chosen by the team. These could be a technical contributor, Scrum master, product owner or manager. The person representing is usually changed every few days or so depending on the team and the stage of the work. Also, more than one person could represent, for example, the Scrum master as well as any developer.

Frequency

Generally, the Scrum of Scrums is conducted on a daily basis, but this isn't a must. This depends on the project needs. The teams decide the frequency of the Meta-Scrums. For example, it could be daily, or twice a week, or less frequently based on the project.

Purpose of Scrum of Scrums

The purpose of the meeting is to achieve better team collaboration on a complex project. These are some of the things it helps achieve:

Make cross-team collaboration easier in case of complex projects involving large teams.
Enhance team productivity in individual Scrum teams.
Make prioritising tasks easier through collaborative discussions.
Solve problems that arise during the course of the development.
Keep the deliverables of the project on track.
Gives a clear picture of the path taken by the team to achieve the goal to all members.
Ensure that the work of one Scrum team isn't a hindrance to other teams.
Combine the productive output of multiple teams effectively into a single entity.

Best Practices for conducting a Scrum of Scrums

By now, you'd have understood most things about a Scrum of Scrums and are ready to conduct these in your teams. To help you with conducting these, here are a few points to keep in mind.

Keep a cap on the amount of time the meetings take. Ideally, keep it at around the same time that your daily standups take.
Set a frequency and stick to it. If your team decides to have the Scrum of Scrums every two days, make sure it happens.
Ensure that each member of the team is aware of what will be discussed during the meeting. The participants should prepare what they want to say to avoid wasting time.
Choose the right person for the meeting. This could vary based on the stage of the project and it's a good practice to alternate members for this.
Make sure that there is time set aside for solving issues. Note that this isn't just to get a status report but rather to tackle issues that come up.
Create an environment of trust and transparency. Team members should feel at ease and share their concerns openly.
Each participant in the Scrum of Scrums should inform their team of the things discussed. This transfer of information is quite important.

Originally published here.

P.S. Also check out these blogs if you liked the above:

Unit Testing in Agile - Getting the Basics right

Rebecca Ferrao — Fri, 12 Nov 2021 12:37:57 +0000

What is agile unit testing?

A unit test is a few lines of code which tests a small part of the product's source code and checks the results obtained. This process of checking the code is called agile unit testing. The developers in the product team make use of this when developing a product.

Unit tests can have either one of two results and are hence binary in nature. The result would be 'pass' if the code acts in accordance with the expectations. If this is not the case, the result would be 'fail'.

Usually, developers write a large number of unit tests to validate the various program behaviors. This makes up a 'test suite'. The results are identified by color code by common convention. The green color represents that all unit tests in a program have passed. Red shows that one or more unit tests have failed. These color codes have been accepted for quite a few years now, dating back to JUnit at least.

'Test-runners' are a type of software to execute unit tests. The developer provides the following info in unit tests:

Brief explanation on what they are testing
The part of software that they want to test (eg. class, function)
Test data to use as input
Expected result

Then, the dev executes their code with the input and compares results with the expected one. You can consider this as a 'pass' when the results of the execution match the expected results. If not, the test is a 'fail'.

In the event that a code depends on external data, it cannot be fully tested. In such cases, the dev replaces the external dependencies with 'mock data'. Mock data is static data that is used to restrict the tests to the functionality of the unit.

History

So how did agile unit testing come about? David J Panzl, a well known agile author, wrote a series of articles talking about tools with features very similar to JUnit. This was in 1976, and these articles testify the long history of automated unit tests.

The years 1988-1990 saw a rise in event-driven GUI software. Testing challenges in these paved the way for capture and replay test automation tools. Companies like Segue and Mercury made these, and they went on to dominate the market for about a century.

In 1997, JUnit, the testing tool, was written by Beck and Gamma. It drew inspiration from Beck's prior work on 'SUnit.' JUnit grew massively popular over the next few years, ending the 'capture and replay' age.

Purpose behind unit tests

Unit testing is popular as it serves the following use cases and makes the life of the developer easier. All these make unit tests indispensable to the development process.

Use of agile unit testing leads to a reduction in the number of defects in the code.
Devs obtain free working documentation of the code through unit tests.
Ease of finding and fixing bugs throughout the development so the end user has a perfect product.
Developers keep in mind the edge cases related to the product automatically. This helps them to identify the best ways of going about things.
The code created is more likely to be modular and reusable, with no dependency.
Others working on the same code would also have no issues in taking over if needed.
Detecting bugs at early stages also saves a lot of money that would have to be spent on fixes later.
Even after the customer uses the product, if a bug appears, unit tests can quickly fix the issue.
Since unit tests use routine operations, the time consumed in manual efforts to test is saved.

How to get started with unit testing in agile?

There are two main steps to unit testing in agile. One is to write code that is testable. The other, to use suitable software to test this code.

The first step, to write testable code, means that the functions you write to test the code should be clean. This means that they shouldn't have side effects and should only work on the given parameters. So, there should be a minimum number of parameters as every new parameter makes testing a lot harder. This is because you then have to test all sorts of combinations with these parameters. There should also be no external dependencies. For this, the mock data spoken of above proves handy.

The next is to use the right tool. A number of tools are used for unit testing in web projects. Some examples are:

Mocha as a test runner in a NodeJS testing environment.
JSDOM for testing DOM interactions.
Enzyme when you want to test ReactJS components.

The app you're developing would decide the unit testing software that you need.

Best Practices for Agile Unit Testing

Some things to remember while making use of agile unit testing are:

Name the test methods such that it makes the need clear and you don't have to look at other places for info. There are many popularunit testing naming conventions you can make use of for this.

Tests should only pass or fail when the code is correct or has an error respectively. This means that if your test passes even when the code is incorrect or vice versa, there's an error in the code.
Try to keep relevant and meaningful failure messages which show the test parameters. The failure message should make it easy for you to correct the error.
Design the test code in such a way that it's got plenty of comments and is easy to read.
Focus on only one test at a time to avoid keeping track of multiple scenarios.
Run tests frequently to ensure correct code.

Originally published here.

P.S. Make sure to check out these blogs, too:

Scrumban: Your complete guide

Rebecca Ferrao — Fri, 12 Nov 2021 12:29:59 +0000

What is Scrumban?

Scrumban is a hybrid agile development framework which combines scrum and kan_ban._ It combines important features of both these methods and is now an agile framework on its own. The structures and routines of scrum are clubbed with the flexibility of Kanban. Thus, it is a very versatile approach to development. This aims to make teams more efficient and productive.

Also, for teams moving from scrum to Kanban, Scrumban can act as an intermediary. A direct transition from one to the other could be hard on teams. Hence, adopting this intermediary makes the transition easier. In fact, this transition was the original purpose of Scrumban. But, this new method isn't as popular as the other two methods which most agile practitioners know of.

So, now that we know what Scrumban basically is, let's understand more about it. We will see how it came about and how it combines the principles of scrum and Kanban.

Scrumban = Scrum + Kanban

To get to how Scrumban combines scrum and Kanban, we need to first see the basics of how each of these works. Then, let's understand how the nuances of either framework are combined together,

Scrum basics

As we know, scrum is a method of agile software development. The scrum framework aims to maximise the speed of delivery and make it easy for the team to adapt to change. Making use of scrum, teams are divided into very specific roles. These roles include scrum master, product owner and the team at large.

When working on a project, the team divides the work among themselves. They stipulate a timeframe for completion, called a sprint. These sprints range from a week to a month on most projects. The team decides what tasks each developer will do during a sprint meeting and the dev then works on just these.

Before every sprint, the team holds a sprint meeting to decide what tasks to take up next and how to divide the work. Also, before each day's work starts, the team meets for a small standup to discuss the tasks.

Kanban basics

Kanban is a visual approach to workload management. The team makes use of a Kanban board andcards to show the status of the project. The tasks are grouped based on the stage they are at in the process. These stages could be named 'To start', 'Work in progress', 'Completed', etc. based on the team and the project.

The team moves the cards containing brief info about the particular task in these stages. Cards move forward or backwards depending on the status of the task. For example, a task could be undergoing review and then move back to 'Work in progress' if changes are needed. This visual representation of tasks makes it easy for the team to understand the project. It also provides flexibility in the process and isn't a rigid structure. Usually, there's a limit on the number of things that can be in progress and this reduces chaos.

Teams that make use of Kanban focus onlead time and aim to minimize this lead time and maximise efficiency.

How does Scrumban work?

Here, let's understand the steps through which Scrumban combines scrum and Kanban. This method applies the flexibility and visualization of Kanban to scrum. It also eradicates the rigidity of scrum and allows room for customization in teams.

These are some of the main aspects in Scrumban:

1. Iterations in Scrumban

Like sprints in a scrum, the Scrumban method focuses on completing the work in iterations. These span over two weeks or so each. But, there are some differences compared to the regular scrum approach.

Unlike scrum, these iterations are shorter and usually don't take over a couple of weeks. Also, instead of assigning tasks, team members are allowed to choose their own tasks.

2. On-demand planning

Kanban functions using need-based planning. This is also emulated in Scrumban. Only when the number of tasks in the 'WIP' column fall, then the planning sessions are held.

There is no set number of tasks that is uniform across teams to mark this threshold. Instead, how many tasks should be there depends on the complexity of the project and the needs of the team.

3. Bucket size planning

To make it to the Scrumban board, the tasks need to go through three different buckets. This putting into buckets of tasks allows the team to plan for the long term. The three buckets are as follows:

One year bucket:

The long term goals of the company are included here. These are usually vague ideas on stuff like targeting a new market or releasing a new product.

Six month bucket:

Broad ideas in the one year bucket are now turned to approved plans and moved to the six-month bucket. The main requirements of the plan are now finalized.

Three month bucket:

When the team is ready to start working on the plans, these are turned into achievable tasks and placed in the 3-month bucket. During the on-demand planning meetings above, the team takes tasks from this bucket.

4. Prioritization of tasks

During planning, the team prioritizes tasks that they can pick from in the order of need. Either numbers are added to mark this or the tasks are placed in columns which show the order.

5. No set roles in Scrumban

In scrum, there are specific roles for team members. In Kanban, the team consists of project management specialists and generalists. Scrumban, on the other hand, gives equal priority to all members. They can choose the tasks they want to work on.

6. Scrumban board

Somewhat like Kanban, the Scrumban board places tasks in 'To Do', 'Doing' and 'Done'. These are then expanded to fit the needs. For example, in the middle section you'd also find Design, Manufacturing and Testing.

7. Scrumban has limits on WIP and To-Do items

As mentioned earlier, a 'WIP (work in process) limit' is also set so that teams do not overburden themselves. A team member works on no more than one item at a time to maximise productivity. Similarly, the number of tasks in the To-do section are also limited.

8. Feature freeze

When the deadline is approaching, a feature freeze is applied. In this, the team doesn't take on any new features and only works on completing the existing ones.

9. Triage

Right after feature freeze, the PM decides which features to actually complete. Only these are then worked on before the deadline and the others are ignored in this iteration.

History of Scrumban

We've earlier established that Scrumban is a way to transition from scrum to Kanban. Corey Ladas, a Lean-Kanban practitioner developed it for this very purpose. He wished to move from scrum to a more evolved framework. Corey is the author of 'Scrumban - Essays on Kanban Systems for Lean Software Development'.

Originally published here.

P.S. Also check out these blogs:

MVP (Minimum Viable Product) - Complete Guide

Rebecca Ferrao — Wed, 03 Nov 2021 10:46:56 +0000

What does MVP stand for?

If you're wondering, 'What does MVP stand for in Lean startup methodology', then, MVP stands for Minimum Viable Product. The textbook definition of this is, 'that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.'

But, what does this definition of Minimum Viable Product mean exactly? And how is it significant? Let's find out.

What is a Minimum Viable Product?

A Lean startup concept, Minimum Viable Product stresses on the importance of learning when developing a new product. As per the textbook definition, this learning will come only when your customers actually purchase the product you are developing. These early adopters are the ones who validate your idea.

Putting MVP into practice is theoretically quite simple. A company launches a new product and tries to gain as many opinions from the early users as possible. The minimum viable product does the main thing that the final product is expected to do. However, it doesn't have any of the additional features that would also be a part of the end product.

The MVP may be as simple as a landing page, that you offer to your customers. They then interact with it and you observe this interaction. Given that this shows you how people actually behave with your product, it's better than just relying on answers from surveys about the product.

How did the term MVP come into play?

You might have seen that in sports, MVP stands for Most Valuable Player. However, the answer to 'What does MVP stand for' in product development is obviously different. This term, MVP in Lean startup methodology was coined by Eric Ries, a well known author and entrepreneur. He introduced this concept in his 2009 book 'The Lean Startup'. This was one of the core business books that was revolutionary in the startup world. Since then, the term has caught on and is now widely used.

In agile development, too, since it's based on creating products based on user inputs, MVP is quite prominent..

What is the purpose behind releasing an MVP?

A company might have multiple reasons behind creating and releasing an MVP:

The product owners may wish to release the end product to the market as soon as possible.
Before spending an excessive amount on developing the full-scale product, the company may wish to test the idea in a trial phase with users. Other features are developed only after testing the customer's response to the product.
They may also want information on what the company's market actually wishes to see and what they do not. The product may entirely change or have quite a lot of differences from the original product that the company envisioned.
To reduce the time and resources that are used on a product when there is no guarantee of success. The developing team spends time only on the bare minimum requirements of the products and nothing more.

To actually see the above outcomes come into play, the MVP should have the following characteristics:

The MVP should have a good enough value so that people are willing to buy or try it in the initial stages.
It should demonstrate sufficient value so that these early users are retained for a longer while.
A feedback loop is created which acts as a guide when developing additional features into future versions of the product.

Minimum Viable Product Examples

Let's see some examples of companies that started with MVPs so as to get a clear idea of how an MVP works in practice.

Farmville

Farmville has heavily used the idea of MVPs in the game. New gameplay features and user experience optimizations were introduced over time and not just on the first release. The customer feedback has been quite important in building the game and continuous changes are made.

Not only Farmville, but most video game companies can be considered as a good example of development using MVPs. These companies start out as early access products and observe user interaction over many months. As the community grows, changes are made before releasing the game.

Foursquare

Foursquare, a location-based social networking platform, was released as a single feature minimum viable product. Only check-ins and gamification rewards were awarded initially. Only after validating the MVP among customers and seeing positive results did they start working on newer features. Recommendations, city guides, etc. are some of what you can see now.

Dropbox

All Dropbox did to show their customers what they could expect out of their end product was create a video explaining the product. This created the initial demand among customers and showed the company that it was worth putting in the finances and efforts into developing a file storage platform. All the features such as file sharing on the go that we now know Dropbox for were developed only later.

Uber

Uber's basic service to the customers has always been the same, right from the MVP. They allowed users to book a cab without having to make a call to a taxi service, and they allowed users to pay without needing a physical wallet. However, since the initial release in 2009, they've developed a number of new features. Now, features such as geolocation sharing, choosing the car you want, calling the driver through the app are all commonly used.

Airbnb

Brian Chesky and Joe Gebbia, the brains behind Airbnb, created a simple site in 2008 offering their apartment for rent. Visitors could see photos and book the apartment for the duration of time they wished to. This was in San Francisco, during a time a large design conference was to be held in the city. The idea hit off and grew tremendously. As of2021, over 800 million guests have stayed at Airbnbs around the world.

What are the basics of building an MVP?

MVPs use a minimal budget and keep plenty of room open for additions. A few steps are involved in creating an MVP in the right way. We've given a brief overview of how to go about it here.

Identify the needs of your customers and the market
You need to first determine whether your basic idea satisfies the needs of your target customer base. Surveys, research and market analytics are useful in this case. Also make sure your product is unique if there are already existing competitors.
Define the idea clearly
Define the value that your product delivers to the market first so that all subsequent features are built to align with this. Your product value should drive the development of the MVP and subsequently the product.
Design the user flow
Choose how you want to present your product to the audience. This should be determined based on user convenience. You'd have to consider a number of factors to come up with the cheapest way of going about this and getting feedback from the users. Design prototypes and work on the best one.
Build the MVP
Based on the prototype you have, build the MVP. This could be time consuming as compared to the other steps here so keep deadlines.
Obtain feedback and learn
Remember that in this stage, the goal is to observe user interactions and learn from it, to make your product better. So, carefully observe how users interact with it and iterate on the MVP so as to make it better.

The above doesn't have to be a once only thing. You can test with different iterations and hypotheses until you come up with the best product for your market.

MVP vs Prototype

You might be familiar with prototypes and hence wonder what is the difference between an MVP and a prototype. Well, prototyping is a part of product design. MVP on the other hand is the product itself. As seen above, prototypes help in eventually building the MVP. Basically, a prototype is a visual representation of the product that you will be building in the future. It is used not only for MVP development but also for the final product if you don't have an MVP.

You may have multiple prototypes visualizing what the end product will look like through many samples. Then, the best sample is chosen and built upon. While a MVP is made for customer use, a prototype is meant for internal use.

Originally published here.

P.S. If you liked this post, also check out these articles on building your startup:

Your guide to Kanban cards

Rebecca Ferrao — Tue, 02 Nov 2021 09:44:53 +0000

What is a Kanban card?

In the simplest terms, Kanban cards are a visual representation of a work item, moving through different stages of completion on a Kanban board. It is the basic element of the Kanban visual system as it shows the work that is already completed, in progress or yet to be started.

Before diving into the specifics, let's understand the very basics of Kanban. Kanban is a work management framework, it makes it easy to visualize the work to be done, limit the work that's in progress and maximize efficiency of the process. The Kanban boards are task boards used for this purpose.

Going back to Kanban cards, to understand what they are, consider a whiteboard as the Kanban board. On this, the software development team uses sticky notes with tasks written on them. These are placed under columns named depending on the stages the tasks belong to, such as 'To be done', 'under development' and 'done'. The sticky notes are then shifted between columns depending on the status of the task.

These cards contain important information about the task at hand as well as its status. The information consists of things like an overview of the task, the person responsible for it, deadline for it, comments among others. All the team members can view these cards at any time and gain info about the project. In this way, the Kanban cards act like information hubs. They are also effective in reducing actual meetings and bringing about transparency in the process.

Kanban cards can be both physical and digital.

History of Kanban cards

Kanban is a Japanese word that literally means 'visual sign' or 'visual card' or 'signboard.' It was conceived towards the end of the 1940s by Taiichi Ohno. He was an industrial engineer in the Japanese car manufacturing company, Toyota, and had been looking for ways to optimize the manufacturing process.

During his research, Ohno observed an American supermarket and saw that unlike usual stores, they didn't keep the inventory fully stocked at all times. Instead, they only stocked shelves that were visibly short of stock, or nearly empty. This shelf was then stocked with just sufficient supply to suit the needs of the customers. Ohno believed that this type of just-in-time delivery could have positive effects on the manufacturing supply chain.

To visualize the manufacturing process, he used Kanban cards. These were used to indicate quantities and signal workers if the quantities drop below a minimum required value. The drop would trigger the replenishment process that will notify the supplier to fill the required items.

The card also contains information about the requirement specifics, making it easy for the supplier to fulfill demands. This system of production was used exclusively at Toyota for a long while and resulted in significant gains.

Around the 1990s, Toyota revealed this system publicly and it was eventually made a part of the Lean manufacturing processes. After this, the Kanban method was adopted widely to optimize processes.

What is the purpose of Kanban cards?

As stated earlier, Kanban cards act as information hubs and bring about transparency in the manufacturing process. The cards also serve some other purposes as follows:

Provide complete details about work items
All the important information about the work items are clearly stated in Kanban cards. Team members can easily see the task overview, the person responsible for a task, its status, due date, links, points about the task, and other relevant data in brief.
Facilitate smooth and efficient handoffs
As work progresses through different stages of the process, Kanban cards prove to be very useful. Expectations are stated clearly and consistently in cards and make it easier for everyone to refer to them. This way, when tasks are handed over from one owner to another, there is no loss of data and all info is available.
More efficient processes
The amount of time a task takes from start to end, known as lead time, is documented in Kanban cards. Using the data available, teams can identify various bottlenecks and find ways to optimize the processes.
Remove the need for meetings to an extent

Since all the information about tasks and processes is easily available on the Kanban cards, the need for team members to physically have meetings is reduced. This way, less time is wasted in unnecessary meetings and it can be directed toward getting work done.

Sides of a Kanban card

All Kanban cards, digital and physical, have a front and back side, each representing different things. Let's understand this here.

Face of a Kanban card

The front side of the Kanban card which you'd be looking at when you look at a Kanban board is used to quickly communicate the most important aspects of the task.

Some of the information you can find on the face of the Kanban cards is:

Title/Identifier - each card has a specific, unique name that shows what is to be done. A number may also be present to help with the identification.
Task owner/manager - The person responsible for the task.
Due date - The deadline or the end date of the task.
Description of the task - what exactly needs to be done under a particular task is briefly described in this field.
Type of work - it shows whether the task is a feature to be developed, a question to be researched, etc. The color of the card usually represents this.
Estimate of time or complexity - each task has a rough estimate of how long it will take to complete, or how much effort it will take.

Back of a Kanban card

The back of a Kanban card is used to display other information which may not be that important at first glance. It gives additional details about the task and is more relevant to only the person doing it.

Information on the back of Kanban cards is:

Scope of the project - when a task can be considered as done is represented here.
Links, attachments - more relevant to virtual Kanban cards, this gives directions to any other relevant information about the task.
Comments - again suitable for virtual cards, it allows team members to share their thoughts on the process
Subtasks - tasks involved under a main task, if any.
Start and end date
Lead time - this shows how long the work takes and how much time one has to wait for new tasks to enter the process

Note that the two sides of the Kanban cards do not always have the same data across industries.

All about Digital Kanban cards

Although Kanban cards, when created, were physical in nature, you can now see both physical and digital Kanban cards. They provide the same basic functionality. Software such as Trello and Jira are used to create Kanban boards digitally and include Kanban cards in these boards. Digital Kanban cards prove to be quite useful for teams that are not colocated, and aid in effective collaboration.

These virtual Kanban cards can be customized with ease, so if you want to show/ hide certain fields, you can do so with a few clicks. Content like comments, links and attachments can also be added to digital Kanban cards.

The present day software is also highly advanced and optimized based on user needs. You can get notifications whenever a card is updated, reassigned or moved to a different stage. Creation of templates that can be duplicated without any extra effort is possible.

Use of digital Kanban cards also makes it easier to track various metrics. This way, you can analyze processes on the go and work on improvements.

Take a small scale example of a project, organizing an event. You'd have to arrange for a caterer, decorator, seating, etc. Each of these becomes a task and you'd make Kanban cards for each and move them across stages. Your friends working with you can also add their thoughts as comments. Links and attachments to various sources can be added with ease when using digital cards.

Originally published here.

'INVEST' in Agile - All you need to know

Rebecca Ferrao — Mon, 01 Nov 2021 11:05:41 +0000

What is agile INVEST?

The INVEST agile acronym is a key to remember a set of criteria that you can use to assess the quality of a user story. It acts like a checklist that has been widely used to assess all the components of a user story. Using the INVEST acronym, a good user story should be:

I - Independent - The Product Backlog Item (PBI) should be self-contained/ independent of others.

N - Negotiable - PBIs are not contracts for features and there should be space for discussion.

V - Valuable - The PBI has to deliver value to the stakeholders involved.

E - Estimable - You must be able to estimate the size of a PBI to a good approximation.

S - Small - PBIs should not be too big and should fit within an iteration.

T - Testable - The PBI description must provide enough information to make development of a test possible.

Product owners should be able to create good user stories to fit the needs of the team. The INVEST acronym is useful for remembering the components of a good user story. Let's understand how each of these components comes into play.

I - Independent

The user stories should be kept as independent of others as possible. 'Order independence' should be aimed for. This means that there is no particular order of going about with the user stories and they can be worked on in any given order, independent of when the other user stories are done. This makes it easier to prioritize a given story over the others if required.

When there are multiple dependencies, prioritization becomes tough. You might have to implement a story which isn't really valuable first. Instead, you'd rather be focusing on the ones which are actually important.

N - Negotiable

Know that a story is not a detailed contract and should be brief. User stories are meant to invite further conversation. There should be room for negotiation. The end goal, of course, should be clearly defined, but, the methods of achieving this end goal should be open for discussion.

The final product should be a result of the collaborative discussions between the various parties. These are the product owner who knows what the customer wants, the developers who work on it and the testers. It should be easy for the various people involved to share their thoughts and changes to the methods should be accordingly made if need be.

V - Valuable

At all points, the story should have a value that can be recognized easily by reading the story. If there is no discernable value to a user story, there is no point of going forward with it. User stories should be prioritized in the backlog based on the value, so this seems like an obvious point.

The team should know why they are building the product. Knowing why they are building it could also encourage your team to come up with other, maybe better ways of going about the story.

E - Estimable

The fourth part of the INVEST agile acronym, to properly prioritize a user story, should be properly estimated. It may happen that a story has a high value but is also very lengthy and this could make you want to keep it at a lower priority. If a story can't be estimated with ease, you could try to split it into smaller components for approximation.

Developers need to have this information so that they can properly size the story to plan and commit to the work. To draw a proper estimate, the developer needs to have domain and technical knowledge as well as the size shouldn't be too big. If the developer lacks the first two factors, they need to make up for it. Talking to the person who wrote the user story can help with domain knowledge. Gaining tech knowledge would need a stint of extreme programming.

S - Small

The exact size, or how small a story needs to be depends on your team and their way of working. Epics, containing multiple stories, can be difficult to work with. Similarly, it shouldn't be too small that it contains just a single step. You need to design your user story around the capacities of your team.

T - Testable

For a story to be successfully completed, it should be tested.. It should be possible to write acceptance criteria/ ensure that the story is testable. Even though there might not already be acceptance tests in place, all the information needed to write them should be available.

As much as possible, tests should be automated. Incremental development could put a lot of things that were formally working into a stagnant state all of a sudden, and automated testing can help identify this fast.

Origins of the agile INVEST acronym

The INVEST agile acronym originally appeared in an article by Bill Wake, in 2003. It was a checklist meant for evaluating user stories.

A year later, in 2004, the technique was recommended in Mike Cohn's book, 'User Stories Applied'. The concept was discussed in detail in the book.

Originally published here.

P.S.
If you'd like, make sure to check these out:

Fibonacci Agile Estimation

Rebecca Ferrao — Thu, 28 Oct 2021 09:52:24 +0000

What is Fibonacci agile estimation of story points?

When you are managing a team, it's important to draw an estimate of how long a task will take and the amount of effort needed to complete it. In agile development, you'd use agile estimation techniques to do this. Using the story points, in Fibonacci agile estimation, is one of the ways of doing this. However, let's break this down into clearer components.

What are story points?

Firstly, agile estimation is the process to estimate the effort required to complete a task.

Following this, story point is the metric used to denote the amount of effort it would take to complete a certain user story. This is what makes the level of difficulty of the user story clear to the team. Developers can get an idea of the complexity, risks and efforts that are a part of the user story.

Story point estimation usually happens during the backlog grooming phase. Estimation isn't the easiest task as a lot of factors have to be taken into account. Instead of hours, taking effort into account is easier, hence story points are used for estimation.

The metric could also be measured in terms of a normal time distribution. Take for example, 1 story point could represent a time range of around 4-12 hours.

What is the Fibonacci scale?

The Fibonacci scale is a series of numbers which increase exponentially. It is used to estimate the amount of effort that will be required to complete a given task or implement a user story. The scale is based upon the Fibonacci sequence and is a series of numbers where each number is the sum of the two preceding numbers. This starts with 0 and 1.

As a quick refresher, the Fibonacci sequence progresses as follows 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 …

What, then, is Fibonacci agile estimation?

Combining our knowledge of story points and the Fibonacci scale, understanding Fibonacci agile estimation is easy.

Fibonacci agile estimation is the use of the Fibonacci sequence as the scale when estimating the amount of effort required in agile development tasks.

Teams discuss the upcoming work and give tasks to each individual by making use of the Fibonacci scale to prioritize tasks that are to be included in the next sprint. The number of story points assigned to a task differ based on the complexity of the task.

How to estimate story points using the Fibonacci scale?

There are multiple ways you could use to estimate the story points in agile using the Fibonacci sequence. We have given two ways of going about with this process below.

In the first way, the product manager or owner gathers together with the team to estimate user stories through the following sequence of steps:

Every team member individually estimates a number on the Fibonacci scale that gives the size of the task in terms of effort.
Then, all the team members present their number at the same time. This is done so that no member of the team is influenced by the estimation of another.
Now that the numbers are all present, these are discussed by all the team members. Based on the discussion, they reach an agreement about the various tasks and user stories.
After this, each user story is added to a bucket which represents the point in the Fibonacci sequence that corresponds to the agreed story point for the task.

These steps are done until all the remaining tasks and user stories in the product backlog are dealt with.

The other way of estimating the story points using Fibonacci agile estimation is the Planning poker approach.

Planning poker approach to Fibonacci agile story points estimation

This way involves giving out deck cards that have numbers in the Fibonacci sequence to agile team members.

Every member is given a deck of cards and the product manager or owner gives an overview of the particular user story or backlog item to start.
Any doubts which may arise after this overview are cleared by discussing these.
Every developer/ tester then selects a card having the Fibonacci sequence number. This is what they feel is the best representation of the effort required for that particular task. The card is then placed face down.
Similar to the first method, the members involved in the estimation process reveal their numbers at the same time.
In the event that there are significant differences in the numbers stated by the people, they justify their number in a discussion.
Once a common value is arrived upon, the team moves on to the next backlog item.

To summarize, the use of the Fibonacci sequence for agile estimation of story points is meant to make it easier to arrive at an estimate that the team agrees on. This is done by allowing each individual to draw an estimate and jointly deciding on the final one, for each user story.

Originally published here.

P.S. If you liked the above article, also check out these articles on startups and product building: