Debts are not bad every time!

Hi Friends, technical debt during sprints is a less discussed but very important topic. Let us discuss this today.

What is a technical debt?

Technical debt refers to the incomplete work in the software systems. It also refers to the shortcuts we knowingly take.

Ward Cunningham (Cunningham 1992) was the first to explain about the concept of technical debt).

Generally there are three types of debts- naive debt, unavoidable debt, and deliberate debt.

Example of Naive debt:

• Incompetent design: This refers to a design that no longer makes sense due to various changes in business.
• Known defects: The known problems in the software that we haven’t yet removed considering these will not impact in immediate future.
• Insufficient testing: This refers to the known areas where more testing could have been done.

Example of Unavoidable debt:

• A third-party component we used in our product and the interfaces to that component evolved over time. 

Example of Deliberate debt:

• Such type of debt is taken to achieve an important short-term goal for example launching a time-sensitive product into the market. 

I remember a few months back my team took a deliberate technical debt by launching a product with USD as the only currency supported. This was because of the business decision of launching the product ahead of the competitors and we were aware that the focus market was of USA. Later we repaid it by providing the multi currency support. 

Today’s technical debt becomes a future work hence it requires a balanced technical and business discussion. Technical debt should be kept low enough to avoid future problems in product development. Also technical debt must be paid off time to time.

A good strategy is to utilize the time we get during sprints when there is some time left in which no next story can be fitted.

When it is not necessary to repay the technical debt?

To repay the technical is not necessay every time. Here are a few situations when technical debt not needs to be repaid.

When the product is nearing to end of life and to repay the debt is not a wise decision.

A product developed for a short life span.

How to repay technical debt?

• During the development activity, whenever a development team member finds a technical debt in the form of any problem, the team member should clean up the problem. 

• Technical debts which are more important should be repaid first. 

• Technical debts should be repaid incrementally time to instead of large late payments.

Technical debt is very important to understand and needs attention & timely repayment. If it is not repaid in time then it may become burden later and impacts on team's velocity.

We will discuss more on technical debt in later posts.

Kenneth S. Rubin (Essential Scrum) has explained about technical debt in a fantastic way. For a detailed explanation readers should refer that topic.

See you soon with more posts…Have a great time ahead!

Estimates are everywhere!

Today we will discuss further on estimating the PBIs.
During product development there are three most important questions which are asked at very beginning.

• Time: When will be the development completed?
• Scope: How many features will be delivered?
• Cost: What will be the cost?

This definitely requires estimating the size of features we plan to develop and the velocity of the team.
How we estimate PBIs?

We estimate Product backlog items (PBIs)/stories using relative sizes, not absolute sizes. There are two most common units of estimation- Story points and Ideal days. In these, ‘Story point’ has got more popularity.

Story points:

Story points are measured considering complexity and physical size of the PBI. PBI may be ‘complex but small’ OR ‘simple but large’ OR ‘simple and small’ OR ‘complex and large’. Ultimately we need to know the efforts required to develop that PBI. This is achieved by comparing stories and putting points on these.

For example, if we compare two stories and find that the latter will take 4 times the efforts than the first, then we estimate the points for second story as points provided to first story multiplied by 4.

A good strategy is to start with the smallest story and providing it point(s). The question is how to provide story point(s) to this story? Let’s assume that the smallest story is about to create a UI for Registration form and the next story which is about integration of a shopping cart in the application, when compared the latter takes 4 times the efforts which first story will take. If the first story is marked with 2 story points the next story will have 8 points (2 * 4).
Ideal days:

Estimation in ideal days is a technique of estimating PBIs and it represents the number of effort-days or man-days needed to complete a story. Ideal time should not be treated as elapsed time/calendar days. Ideal days are total effort in days and can span for many days as per the hours utilization per day.

What is velocity?

The amount of work completed in a sprint is known as team’s velocity. After each sprint the size of completed PBIs is added and that constitutes the velocity of the team. Partially completed PBIs

are not included in the velocity as they do not have any value for the product increment.

To know the number of sprints for the release, size of the release is divided by the team’s average velocity. So for example if the release has 500 points and the average velocity of a team is 50, then it will require 10 sprints for that release.

Planning Poker

Planning Poker is a technique for sizing PBIs. Planning Poker was first described by James Grenning (Grenning 2002) and popularized by Mike Cohn (Cohn 2006).

The game begins…

The Product owner describes the PBIs and the ScrumMaster closely monitors, guides and motivates the team to participate in Poker planning.

Each development team member is provided with a set of Planning Poker cards for this game.

The product owner selects a PBI and reads the item to the team. Development team members discuss the item and ask questions to the product owner if any clarity needed on that PBI. Each member of development team selects a card representing his estimate without disclosing it to other team mates.

Once each estimator has made a private selection, all estimates are simultaneously shown to all estimators. If everyone selects the same card then it becomes the PBI estimate. If the estimates are not the same, the team members discuss and repeat the same until consensus is reached.

In no case average of the estimates is agreed as an estimate for any PBI.

This is how we estimate the tasks and velocity. If more clarity is needed on any point, please let me know. I will try to reply as soon as possible…

User stories continued...

In continuation of previous post…

Overview of User Stories:

Traditionally user stories are hand written on paper cards. Some times we use colored sticky to write story and place them over a wide board where each team member can easily view.  In addition to it there are many tools to help write and manage user stories. Rally and JIRA agile are a few I generally prefer.

It is not required to write all details as stories. Instead the development team and the customer discuss these details and make a few annotations on a story card based on the discussions.

Generally a story writing workshop is conducted to write the stories in the initial phase of starting the project, but this is not a strict rule. Stories can be written at any time throughout the project. Though the Product owner is responsible for writing the stories but the whole scrum team including domain experts do the brainstorming and facilitate Product owner during the story writing.

Each story is estimated in story points by the development team. Story points indicate the size and complexity of the story relative to other stories. These story points are very useful to determine the velocity of the team. We will discuss velocity in future. In short we can say that velocity is the number of story points the team think will be complete per sprint.

Acceptance Tests:

Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer team expected it to work. The back of a story card holds reminders about how to test the story. These can be added of removed any time.

These tests capture the expectations of the stake holders that should be handled by the system.

User Roles:

It is very important to understand that there may be different users of the product/software. Every user has different perspectives and goals towards the product. This is the reason that before writing stories different user roles should be taken into consideration. For example in a B2B or B2C product there may be internal customers, external customers, admin group etc. Thus this will have significant impact on user stories. A very fantastic way to achieve the user role is to have persona. Think for it…and compare with avatars. I truly look forward to your views on it.

Techniques to write stories:

There are many techniques and a few are as below.

• Story-Writing workshops

• User interviews

• Questionnaires

• Observation

Estimating user stories:

User stories can be estimated in story points. Planning Poker is one of the techniques first described by James Grenning (Grenning 2002) and then popularized by Mike Cohn (Cohn 2006) is my favorite. We will see this technique in near future. For the fast and furious scrum followers check out your mobile devices (I used the android play store), you will find many fascinating tools free of cost for planning pokers.

User stories are further broken into tasks. Tasks help us to develop in a calculated way.

There is an acronym for creating effective tasks: SMART’.

S – Specific

M – Measurable

A – Achievable

R – Relevant

T – Time-boxed

Caution: Estimation is the part which is most concerning to each stakeholder. Let us discuss it further. I expect a few questions from all reviewers of this post. Till then ‘Have a great day ahead’.

Scrum in action...

Today I will tell an old story I heard in my childhood. You all might have read this.

Once upon a time, there lived six blind men in a village. One day an elephant came in their village. They had no idea what an elephant is. They decided, "Even though we would not be able to see it, let us go and feel it anyway." All of them went where the elephant was and touched the elephant.

"Hey, the elephant is a pillar," said the first man who touched his leg.

"Oh, no! it’s like a rope," said the second man who touched the tail.

"No! it’s like a thick branch of a tree," said the third man who touched the trunk of the elephant.

"It is like a big hand fan" said the fourth man who touched the ear of the elephant.

"It is like a huge wall," said the fifth man who touched the belly of the elephant.

"It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.

They started arguments as per their perspectives. One passerby explained to them, "All of you are right. The reason every one of you is telling it differently because each one of you touched the different part of the elephant. So, actually the elephant has all those features what you all said."

Yes, you all got it right. Elephant is what we call an epic and the body parts are user stories. If the big picture is not known to all six men together, individually they will perceive it like pillar, rope, branch of tree, hand fan, huge wall and solid pipe.

This is the reason we all attend the daily scrum to understand the big picture and inspect & adapt. We review the development and do retrospective for improvement so that all parts get developed and integrated correctly. After all, all parts should be at appropriate place to complete the elephant.

Lights…Camera…Action!!!

Epic:

When a story is too large and estimation in nearly impossible it is referred to as an epic. Epics need to be further split into stories of smaller size.

Sample of epic:

As a user, I can backup all of my hard drives.

User Story:

A user story describes functionality that will be valuable to a user of a system.

Sample template for user story:

As a <type of user>, I want <some goal> so that <some reason>.

User stories are composed of three aspects:

• Written description: This is description of the story used for planning and as a reminder

• Conversation: Conversations about the user story serve to flesh out the details of the story

• Tests: Tests convey and document details and that can be used to determine the completeness of user story.

Who writes user stories?

The customer team writes the user stories. This is because the user story should be written in the language of the business. Also the customer team can prioritize the stories for inclusion into iterations and releases.

INVEST in the user stories:

Good stories have six attributes. Bill Wake, author of Extreme Programming Explored and Refactoring Workbook, coined the acronym INVEST for this.

So what is INVEST? 

• Independent

• Negotiable

• Valuable to users or customers

• Estimatable

• Small

• Testable

We will go into details of epic and user storied in my next post. Please post your feedback and queries so I could include the reply in my next post or try my best to reply as soon as possible. 

Setting up the stage...

A scrum often restarts the game. I am not joking. But yes, I am referring the game ‘Rugby’.

And the term Scrum has been borrowed from Rugby.

Let us understand the other terms used in Rugby, I mean in Scrum practices. 

We will start with the roles, artifacts and activities used in Scrum.

Roles in Scrum: Three 

• Product Owner
• Scrum Master
• Development team

Artifacts: Three

• Product backlog
• Sprint backlog
• Potentially shippable product

Activities: Seven

• Product backlog grooming
• Sprint planning
• Sprint
• Daily scrum
• Sprint execution
• Sprint review
• Sprint retrospective

Let us have a glance on the Roles in scrum team:

Product Owner is a central point of product development. He works in two directions, collaborates with the stakeholders (internal & external) as well as with the development team.

In addition to it Product owner creates and grooms the product backlog, plans for sprints and releases (…of course with the help of scrum master and development team).

ScrumMaster acts as agile coach for the development team and the product owner. ScrumMaster helping everyone understand and embrace the Scrum values, principles, and practices. A ScrumMaster provides process leadership, helps the Scrum team and the rest of the organization develop their own high-performance, organization-specific Scrum approach.

As a servant leader of the Scrum team a ScrumMaster is an impediment remover for the team.

Development team is a cross-functional collection of people which includes architect, programmer, tester, database administrator, UI designer and others. The development team has T-Shaped skills and thus such diversity typically leads to better outcomes in terms of faster solutions and higher-quality deliverables.

Here go the Artifacts:

Product backlog is a list of desired product functionalities. Priority of these functionalities is determined by Product Owner. Product backlog provides a centralized and shared understanding of what to build and the order in which to build it. Product backlog consists of Product Backlog Items (PBIs).  The PBIs are represented in the form of User Stories.

We will discuss the User Stories in length later.

Sprint backlog is another list to ascertain what it can get done in sprints**. Development team breaks down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog -Sprint backlog.

** A sprint is timeboxed duration generally from 2 to 4 weeks in length.

Potentially shippable product is one that can be released if found appropriate at the end of each iteration. At the end of sprint execution the team produces a potentially shippable product increment that represents some of the product owner’s vision. Potentially shippable means that there isn’t materially important undone work that needs to be completed before we can ship the results from the sprint. It is not necessary to have release after every iteration. A set of features from multiple iterations can be released together.

A brief description of Activities: 

Product backlog grooming refers to creating and adding details to PBIs, estimating PBIs, and prioritizing PBIs. Only Product owner is the decision maker in grooming though scrum team significantly participates in this activity.

Sprint planning is the activity to finalize the PBIs on those the Scrum team will work in next sprint. Sprint planning occurs at the beginning of each sprint. In this activity the team generates a sprint backlog of the tasks that has to be completed in a sprint.

Sprint is iteration of up to a calendar month called sprint. Sprints are timeboxed, have a short and consistent duration, have a goal that shouldn’t be altered once started (except the extreme urgency), and must reach the end state specified by the team. Usually sprints are planned for 2 weeks to 4 weeks.

Daily scrum is a timeboxed activity (15 minutes max) referred as the daily stand-up to inspect and adapt the big picture plan for that day. ScrumMaster facilitates daily scrum and each team member takes turn answering three questions for the benefit of the other team members:

1. What did I accomplish since the last daily scrum?
2. What do I plan to work on by the next daily scrum?
3. What are the obstacles or impediments that are preventing me from making progress?

Such communications are helpful to identify obstacles and enable a better flow through sprint execution.

Sprint execution is an activity towards the work necessary to deliver a potentially shippable product increment by the scrum team. This is the work the Scrum team performs to meet the sprint goal.

Sprint review is a very important learning activity where a scrum team inspect the result of the work (the potentially shippable product increment). The sprint review occurs near the end of each sprint cycle, just after sprint execution and just before the sprint retrospective.

The sprint review provides a close look at the current state of the product. It is the time to ask questions, make observations or suggestions and have discussions about how to best move forward.

Sprint retrospective is an opportunity for scrum team to examine what’s happening, analyze the way team work, identify ways to improve, and make plans to implement these improvements. It is important because it gives teams the chance to customize Scrum to their unique circumstances.

In our next posts we will explore all these one by one at length.

Talk of the town!

It was the talk of the town! We were involved in a product development and everyone in my team was talking about following Agile practices. Lots of ideas were flowing… ‘Rapid development’, ‘Scrum’, ‘Sprints’, ‘Regular feedback from client’, ‘Iterative deliveries’ and many more.

The product was delivered in releases as planned and of course in time. Partial Scrum was followed as the Agile practice. Don’t be furious!!! you scrum masters…

I agree there is nothing like ‘Partial Scrum’. It’s either Scrum or not. So what’s the heck is Scrum?

A view from 30,000 foot...

Scrum is an agile way to manage projects. Usually scrum is practiced in software development. It is a people-centric framework based on the values of honesty, openness, courage, respect, focus, trust, empowerment, and collaboration.

Scrum team consists of three roles:

• Product owner: The most empowered central point of product leadership.
• Scrum Master: Acts as a coach, providing process leadership, helping the Scrum team and the rest of the organization develop their own organization-specific Scrum approach.

• Development team: A cross function, diverse people who are responsible for designing, building, and testing the desired product.

We will discuss these roles in length later.

Why Scrum?

• Risk Mitigation due to faster feedback cycles.
• Reduced time-to-market hence improved ROI
• Improved stakeholders satisfaction
• Confidence to succeed in a complex product development

I’m sure one question must be bouncing in your mind, which kind of domain we should start with Scrum.

In next chapter we will find out among the below domains which are best suited with Scrum.

1. Complex domain
2. Complicated domain
3. Chaotic domain
4. Simple domain
5. Domain in Disorder
6. Interrupt-Driven Work

Pitch to practice Scrum...

          During a conversation today my friends, software project managers and scrum masters in Pune, asked me about my voyage from Indian Air Force to software development and the motivation to adopt Scrum for managing projects. The most motivating instance for me to dive in this new role is that I have served Indian Air Force for almost 20 years and -Jeff Sutherland, the creator of Scrum was a fighter pilot in US Air Force. So I can proudly mention it as an ‘Air Force effect’. :-) 
More on this in future…..
Let’s move further to see what are the domains best suited for Scrum:

• Simple domain: The domain where everyone can see cause and effect, scrum may be used but not the best fit. For example, if we want to reproduce the same product over and over again, a well-defined assembly-line process would be a better fit than Scrum.

       Situation-appropriate approach:

• Sense
• Categorize
• Respond

• Complicated domain: Complicated domains need good practices dominated by experts. For example, code optimization/query optimization for better performance, Scrum can be applied here but not the best option.

 Situation-appropriate approach:

• Sense
• Analyze
• Respond

• Chaotic domain: In such domains due to crisis there exists need to act immediately, a rapid response.

         Situation-appropriate approach:

• Act
• Sense
• Respond

• Complex domain: Such domain is the domain of emergence and need creative and innovative approaches. Such domains are best suited for applying Scrum framework.

 Situation-appropriate approach:

• Probe
• Sense
• Respond
• Domain in Disorder: Disorder domain when it is not clear which of the other domains one is in. Time is to interpret and act accordingly.

                 Situation-appropriate approach:

• Break down the situation into constituent parts
• Assign each to one of the other four domains.

1.       Simple

2.    Complex

3.   Complicated

4.   Chaotic

• Interrupt-Driven Work: Domain with the frequent change such as support requests is not meant for Scrum.  Kanban is the best suited for such domains. We will discuss on Kanban in near future.

  Situation-appropriate approach:

• Visualize
• Limit work in process
• Manage flow

 We will explore Scrum in next post very soon.....