"TUFE" is not TOUGH to understand!

I believe you are thinking "Ok, it's not tough to understand, but what is TUFE by the way?" So, TUFE is something which confused many of us many times and it is:-

T - Tasks
U - User Story
F - Feature
E - Epic

Most of the time, for most of us it is difficult to understand these & differentiate among these. I've tried to explain this here in the simplest way. Let's see!

First, consider the below Release plan & hierarchy from any organization for a particular Calander Year:-

As per this plan:-

1. The organization has 4 Releases in a year.
2. Each Release occurs after 3 Sprints. Therefore, the deliverable of 3 sequential sprints will be the part of MVP in a particular release (R#.#)
3. Each sprint has 30 calendar days.
4. The organization has taken the decision to have 6 hours capacity per person per day. So, there are 6 hours a Day. 

This was the top-to-bottom hierarchy of Releases.

Now, Secondly, consider another hierarchy and see how TUFE is placed:-

As per this hierarchy:-

1. Epic is the highest level requirement. It contains multiple Features.
2. Feature consists of the number of user story.
3. User Story consists of the number of tasks.
4.  Task is the lowest level requirement.

The interesting thing is that Release Hierarchy and TUFE Hierarchy is related to each other and has some relationship. Let's consider the below diagram and then let's try to find out the relationship in these:-

What does this relationship mean? 

It says:-

1. Epic - The high-level requirement which shall be completed in multiple releases and cannot be completed in a single release. E.g.- Create an e-commerce website.   
2. Feature - The high-level requirement which shall be released in a single release but cannot be completed in a single sprint. There will be more than one sprint to implement this requirement. E.g.- Implement Payment Gateway in e-commerce website
3.  User Story - The requirement which shall be completed in a particular sprint but can or cannot be completed in a single day. E.g.- Create Payment Gateway page as part of Payment Gateway implementation in E-Commerce website.
4. Task - The lowest level requirement which is the subset of a user story. It shall be completed in a particular day but can take a number of hours in a single day (say 3 hours out of 6 hours). E.g.- Add Image for Credit/Debit card option at Payment Gateway Page etc.  

Was TUFE tough to understand, really?

AGILE: Inculcating The Culture of CI & CD (Continuous Integration & Continuous Delivery)

Agile, whether considered as Culture or Framework, is attracting many around the world. In the world of complex development & rapidly changing demands, agile is inculcating the culture of responding to the customer’s changing requirement & deliver the concentrated business-value in the form of the product. Agile does this in many ways & CI/CD is one of them. Let’s dive into CI/CD & SCRUM and see how SCRUM can facilitate the CI/CD & ensure that extensive business-value is being delivered to the customers.

What is CI / CD (Continuous Integration / Continuous Delivery)

The development of complex product needs a long timeline & most of the times more than one team works together to deliver the common product. All these teams work in same iteration/sprint. At the end of the sprint, all teams deliver their MVP (as a part of sprint deliverable) & all these MVPs from different teams combinedly becomes the Product Increment (PI).

Lets’ understand CI & CD:

Continuous Integration (CI):

Most of the time, during the development of complex products, the work is done in sprints/iteration & by the different-different members of the team. They share the same code base & continuously enhance/update the code to implement new functionalities/enhancements.

“Continuous integration is the process in which multiple members of multiple teams write the code in the same code-base in such a way that the newly added code is merged into the older code without breaking anything.”

To understand the concept of CI, consider the below diagram:

Dev1, Dev2…& so on are working on the same codebase for their respective implementation (on their respective User Stories). After the completion of implementation, all developers do the unit testing to test the implementation. After that, they transfer the code to ‘Test Branch’ where QAs execute the testing. Once the QA is completed, the code is merged the Source Code Master(SCM) branch. Now, this SCM branch has all the code from multiple developers. Then, this SCM branch code goes for build & the updated functionality is ready for Integration Testing. Now, these integrated functionalities pass through the “Integration Test” which ensures that “all the integrations done into the code are bug-free & not breaking anything.”

In this way, Continuous Integration is implemented.

Continuous Delivery (CD):

Continuous Delivery (CD) is the mechanism which ensures that “product can be released anytime”. As we have seen earlier in Continuous Integration, teams work in multiple iterations & continuously integrate the new code into the Codebase to implement the new/required functionalities.

Continuous Delivery goes one-step ahead to the Continuous Integration. Consider the below diagram: -

As this diagram depicts, after the Continuous Integration, Acceptance Test is performed over the integrated code base to ensure that:

•        The integrated code is In-line with the expectation of the client
•         Integrated code Does not have show-stopper issues
•         Integrated code Pass through the Acceptance Test phase, &
•         It Can be released anytime to the client

After passing the Acceptance Test, the product becomes eligible for release & to be deployed in production.

In this way, this is the concept of CI / CD.

Let’s dive into the SCRUM now.

What is Scrum

Being one of the methodologies under Agile Framework umbrella, Scrum ensures the iterative development. Originally, this term has been taken from RUGBY. Consider the below diagram:

Scrum is an iterative development cycle. These iterations are called sprints. Each sprint has a definitive goal which is based on the customer’s vision & business-value. Before going further, let’s consider the below SCRUM cycle: -

 As shown in diagram, there are below steps involved in the Scrum cycle: -

1-     Stakeholders / Product Owner meet the customer & brainstorm the customer’s requirement. They prioritize or outline the work that needs to be done as a product in general & in upcoming iterations (aka Sprints) as specific. As a result, the Product Backlog is prepared. This backlog shows the roadmap & vision of the product.

2-     There are some refinement sessions organized by Product Owner with Scrum Team (Developer, QAs, Architects) & Scrum Master. The story point estimates, dependency, blockers & other required details come to the surface for the user stories which are present in Product Backlog.

3-     Then, Sprint planning comes into the picture. Scrum Master leads this ceremony with Product Owner & Scrum Team. The refined Product Backlog is taken as input for this sprint planning & on the basis of capacity & required business value, User Stories are shortlisted from the Product Backlog to be taken into the sprint. Now, Sprint Backlog is prepared & sprint is kicked-off.

4-     During the Sprint, team works on the Sprint backlog item (finalized in #3) & perform the daily ceremonies. Scrum Master is the responsible to keep team away from distractions & remove their blockers & dependency.

5-     Finally, the team come up with MVP (Product Increment / Minimum Viable Product) which is called the sprint deliverable.

6-     This MVP is demonstrated to the Product Owner, Stakeholder & business people & collect the feedback, suggestions.

7-     Then, Scrum Team with Scrum Master goes to retrospective meeting. It can be considered as “Lesson Learned” meeting where the team members keep trust & respect to each other & feel free to put their concerns before the team.

8-     Product Owner, stakeholders & client meet to discuss the requirement shift or priority shuffling. Accordingly, the changes need to be adjusted in Product backlog. Again, the cycle from #2 runs on. It goes continuously.

This is the complete Scrum Cycle.

Now, after having the understanding of CI/CD & SCRUM, let’s see how SCRUM facilitate the CI/CD in the projects.

SCRUM and CI / CD

We have seen SCRUM, CI & CD in this article & understood these concepts. Now, the question is How SCRUM is the facilitator of CI & CD? Consider the below facts: -

1-     In SCRUM, there is an iterative (aka Sprint) approach to development. In each Sprint, Scrum Team develops the solution & deliver the MVP

2-     Multiple members of the Scrum team work for the same product & share the same codebase

3-     After the iteration, all these newly implemented solutions merged into the original codebase & product increment take place. This product which is ready after the iteration with newly implemented functionality, is called MVP (Minimum Viable Product)

4-     The solution becomes ready to be released to the client after the iteration. It is done after Integration & Acceptance testing.

Along with these facts, consider the below SCRUM cycle again:

The scrum cycle runs in 1-4 weeks’ time window & this is the duration in which Scrum Team develops the solution for new requirements. These members use their respective development branch & transfer the code to Test branch for QA process. QA team collects the multiple solutions from the multiple members & run the Integration Test. All this work is done in the iteration or Sprint. When the QA is successful for all these multiple implementations, this solution is merged into the Master Code base & Integration testing takes place. After this testing, the product is ready to be deployed.

Therefore, SCRUM facilitates the continuous integration because all the development is done into the iterations & after each iteration, the newly developed code is merged into the original codebase without breaking anything.

When the Sprint ends, Sprint Demo ceremony is organized in which Scrum team runs the Demo of newly developed features. This complete Product (Older product, with newly implemented features aka Increments) is always ready to be released to the client.

Scrum ensures that after each iteration/sprint, the product should be able to be released & it is called the Minimum Viable Product. Because it is ready to be released anytime, it facilitates the Continuous Delivery.

Conclusion

Agile has become the culture which ensures that “the change in requirement from client does not go unheard”. Agile made the process so mature that teams are always ready to embrace the change & deliver the product which truly delivers the business value. Agile made it possible by introducing the culture of “Deliver in Iterations”. And, when it comes to working in iterations, CI & CD automatically comes into the picture because these iterations are continuous & in each iteration, teams are continuously integrating the new features & continuously delivering it to the client so that it can generate continuous business value to them.

Scrum facilitate the Sync between Customer’s Journey & Product Journey. AGILE-Scrum & CI/CD are not only the process to develop the product, rather these are the culture of respecting the ‘Changes’ & deliver something which gives multiplied business value.

Thinking Scrum? Let’s Play RUGBY!

Agile is becoming popular day-by-day. Agile, as a CULTURE, is becoming the lifestyle rapidly. It is exciting to know that agile is being used in all sort of industries like Software, Automobiles & Event management (e.g. - Weddings etc. See my blog - Getting Married? ‘AGILE’ Is Here to Help You!). To achieve Agility, there are number of frameworks available and Scrum is the most famous one. It is more exciting to know & understand Scrum in a RUGBY Way.       

Rugby is a game which follows the same sort of spirit as Scrum does. In Rugby, every member of the team has the responsibility to take the ball & touch the goal post. All the members unite together, play as team & work towards the same goal. Scrum teams, in the same way, unite & work together to deliver the MVP (Minimum Viable Product) after each iteration a.k.a. sprint. MVP can be considered like a Rugby ball.

Both Scrum & Rugby show the same thing:  One Team – One Ball - One Goal!

Except for the subject matter, Agile & Rugby have same characteristics as:

1-    Team Spirit – We, not ME!

Every member of the team shows the extensive amount of team spirit & ultimately these team-spirits & support results in the success. They all are dedicated & accountable to the goal & team. These team-members shows the unconditional support, trust & respect to each other.

2-    Adaptable Team

Both Agile & Rugby teams are highly adaptable. They are not bound to predefined strategies. Whether it is related to change the strategy at the playground or embracing the change as per customer’s requirement, they are accepting these & preparing themselves for these changes rapidly.

3-    T-shaped Skilled Team

These teams are cross-functional. Every member of the team is able to perform any required action & at the same time has expertise in some area.

What AGILE adopted from Rugby?

AGILE is an umbrella under which a number of frameworks fall like Scrum, Kanban, XP & Lean etc. Industries have adopted methodologies out of this list as per their requirements. E.g. – Toyota took Lean & Kanban; ThoughtWorks took XP. As you see in my previous blog, few Wedding planners adopted Scrum. 

Scrum is one of the most famous frameworks. Do you know the roots of SCRUM?

Yes, Rugby has given the concept of SCRUM. Scrum is the style in which players pack closely, play for the same goal & restart (after an interruption/iteration). In the same way, SCRUM is used to achieve goals in iteration by closely packed teams.

AGILE / RUGBY: Roles & Conflict Resolution?

The teams are the group of human & every human is unique. This uniqueness brings the differences among the human and so team-members. So, having conflict is obvious & that is why resolving them becomes undeniable.  

AGILE Teams have 3 roles which have the direct correlation with Rugby teams:

1-    Product Owner: The one who has the vision of product, strategy & what needs to be done on the playground (or workstation)

2-    Scrum Team: Cross-functional team working to achieve the same goal

3-    Scrum Master (or Referee): Performing roles like Facilitator, Information Manager, Conflict Resolver & Distraction Remover that too without having an authority within the team. 

The most important thing in Agile Teams is they are self-organizing teams. No manager kind of role is required because these teams are able to identify their action-items rather than being directed by Manager.

As we have seen the characteristics, roles & the performing techniques both in AGILE & RUGBY teams, it is not wrong to say that both have too much as common & inspired by the same spirit.

Think, Both Agile & Rugby are not like:  One Team – One Ball - One Goal – Similar Role!

But finally, it is not a strategy or planning or management which works alone for AGILE/RUGBY team. What really matters are the Team Spirit, Respect, Dedication, Self-organization, Cross-functionality & Work Towards the Same Goal and are these not creating A CULTURE when combined?     

Getting Married? 'SCRUM' Your Wedding!

Getting married is the wonderful & unique feeling. It fills you with joy & happiness and you enjoy the new experiences. But is the marriage a result of one-day preparation? Doesn’t it need planning & execution of those plans? Is marriage-preparation lesser than a PROJECT?

In reality, Marriage is not less than a project. It needs

• proper planning,
• prioritizing the things,
• proper execution of plan &
• that too keeping budgeting & schedule in mind. 

And hence, it is not lesser than the Project.

SCRUM: For Wedding?

I always recommend that AGILE / SCRUM is a way to execute the things & it is not limited to certain kind of purpose. I got the confidence when one day during browsing I found a website http://www.scrumyourwedding.com/. The Owners of this website nicely coined the concept of MVW (Minimum Viable Wedding) and soon, I was able to outline the SCRUM cycle to get MVW:-  

  

The Scrum Roles into a wedding:

Scrum defines 3 roles: Product Owner, Scrum Team, Scrum Master. These roles have beautiful relevance in preparing a wedding: -

•  Product Owner(PO): Like software/other projects, She/he is the whole & sole responsible for MVW. PO prioritize the list of to-do (say Product Backlog) by considering all factors like budgeting, schedule(timeline) & available-capacity.
•  Scrum Team: It is the team who execute the plans & convert vision into reality.
•  Scrum Master (SM): Most of us have experienced the conflicts during the wedding cycle for some reasons. It is the responsibility if SM to get these conflicts resolved & keep Scrum Team unaffected.

Scrum Ceremonies:

Scrum ceremonies like Sprint planning, Sprint review, daily stand up are necessary to plan the next iteration of planning & preparation. It’ll give you an idea where the improvement is required.

Scrum MVP as Wedding Rituals

The wedding is not a single activity/ritual rather the collection of different rituals. In Scrum, after every iteration, MVP is delivered which shows the development progress towards the product. Likewise, in wedding, these rituals are MVPs which are delivered/celebrated in a certain time (say iterations). Here too, these MVPs/rituals show the progress towards Minimum Viable Wedding & keep motivated to be in rhythm.

Earlier, we have seen that different type of organizations have adopted Agile in their production house & get the benefit of it by producing the different-different product. But using AGILE/Scrum for a wedding really means that “Agile has touched our personal life”. Agile, in reality, is a culture of:

• visualize the progress regularly & getting things done on time
• detecting problems as early as possible getting things done as expected
• resolving conflicts & getting things done as planned
• getting things done as & when required  
• getting things done as much as required

Good Luck & congratulations, if you are getting married soon.

AGILE Estimates: The relation among Estimates, Estimation-Techniques, Project-Planning & Business-Value

Let’s start with following questions & try to estimate: -

1-      Approximately, how much time will it take to go from Delhi to Chennai (Distance between the cities = ~ 2200 KMs.)?

2-      Approximately, how much time will it take to go from Delhi to Noida (Distance between the cities = ~ 30 KMs.)?

And the condition is “Mode of travel” is same in both scenarios, say By Road.

INTRODUCTION

Estimation is the process of ‘evaluating something by keeping its constraints in the mind’. At each step in our life, we go through this process & make our decisions. From shopping to investment, from exam-preparation to games everywhere we do an estimate. It is not wrong to say that “In Life, if you have taken any decision, you’ve DONE the Estimation”.

Projects are not an exception. Software Development Life Cycle starts with Requirements & Analysis and runs until delivery. At each phase, estimation is done. Project Estimation is like “What & when can we deliver?”     

AGILE Estimation techniques are the process of estimating the work in the project & try to find the answer “What & when can we deliver?”

In Agile, there are different ways & techniques of the estimation which cater different purpose. Mainly estimates are of 2 types:

                                                                             

HIGH & LOW-LEVEL ESTIMATES & ESTIMATION TECHNIQUES

In Agile, any project is delivered as multiple MVPs (Minimum Viable Product) in defined iterations (aka. Sprints). Before project start & during the development of a project, Product Owner takes input from Customers & stakeholders and manages the product backlog based on the requirements, suggestions & feedback received from them. Customers & Stakeholders provide their input based on the business value of the features of the project. Hence, the product backlog is something which shows the Vision of stakeholders & business value of the product. The items will be picked from this product backlog & put into the sprint backlog for the next sprint (iteration). BUT “Shall we pick items randomly from product backlog?” No, and now HIGH-LEVEL ESTIMATES comes into the picture. Let’s see what that is!

HIGH-LEVEL ESTIMATES

Consider an Iceberg as a project. See below picture: -

Suppose an ICEBERG is like a product which we must develop & deliver. The area which is under-water shows the Product Backlog/Wishlist & will be delivered in future releases. The items will be picked up from product backlog & will be moved to Sprint backlog & these items will be released as MVP at the end of the Sprint.

HIGH-Level Estimates help Product Owner(PO) & Stakeholders to prioritize the product backlog item, long-term planning of product deliveries & set long-term goals. But How High-level estimate helps?   

                                                                                                       

T-Shirt Size Estimation – This is the technique to estimate the epics & features. The sizing is provided as S, M, L, XL, XXL. The team sits together with PO & gives a very high-level estimate based on this sizing. This is the way to estimate Epics & Feature.

SWAG (Scientific WILD-ASS Guess) - This is also the technique to estimate the epics & features. The sizing is provided very vaguely but in points. E.g., - 600 points etc. The team sits together with PO & gives a very high-level estimate.

Relation with Business-Value – When these high-level estimates are collected by PO, She/he discusses this with stakeholders. They brainstorm & compare the estimates against the business value of each Feature. Because of this brainstorming, PO gets the prioritized product backlog as per business value & size.

This is how High-Level estimates works in the Product journey & helps in product planning.

LOW-LEVEL ESTIMATES

Now the Product backlog is prioritized (using High-level estimates) & having the user stories for long-term planned Epics & Features and we are in Sprint planning ceremony. Each item/story from product backlog will be estimated individually & moved to Sprint Backlog. These estimate which is more specific, detailed, based on each & every detail of work required in the story, are called low-level estimates. There are 2 techniques of Low-level estimation:

Story Points – Generally Poker Card is used for these estimates. The team will go through the “Acceptance criteria” of the story & ‘Definition of Done’ & comes up with story point estimate. The sizing is any of 0, 0.5, 1, 2, 3, 5, 8, 13, 40, 100, ? and (infinity). Finally, these are the estimates which are reflected in velocity because These estimates estimate the business value which will be delivered.

Clock Hours – This is the absolute technique of estimating the work. The team split User stories into task & give Hour-estimates. The sizing can be any positive number. These are the estimates which are reflected in burndown chart & shows the daily progress of the project. These estimates estimate the individual’s capability to complete a particular task and that is why the summed-up capability set the starting point marker in burndown chart.   

                                    

                                                                                                        

Relation with business value – After each sprint MVP (which is a part of the feature) is delivered. These story point estimates set the velocity of the team. When stakeholders brainstorm the priority of new feature or epic based on business value & timeline, they consider:

1-      The Business Value of the Feature

2-      The total rough estimates (High-Level estimate) received for a Feature (Say it Distance or Volume)

3-      The velocity of the team (Say Velocity)

        

When velocity & Distance/Volume is present, a stakeholder can easily estimate the TIME of getting this new feature delivered. They Compare it with its business value & prioritize into Product Backlog. And then, the same cycle goes on for this feature to be delivered as MVP in next Sprint.                 

          Now, remember 2 questions from which we started. Just think of your answers: -

In our answers (or estimates) of these questions, we are clearer about time from Delhi to Noida journey rather than Delhi to Chennai. The reason is lesser volume (or say Distance), Lesser chances of blockers, lesser complexity & lesser uncertainty.

Therefore, we can consider: Delhi To Noida à Sprint Backlog Item (as User story)

     Delhi To Chennai à Product Backlog Item (as Epic or Feature)

Now, as we have seen above, how we should estimate these: -

Delhi To Noida à Sprint Backlog Item (as User story: Estimated as low level – 3 Story point or 1 hour)

Delhi To Chennai à Product Backlog Item (as Epic or Feature: Estimated as high Level – 100 Points or XXL)

Conclusion

The Epics/Feature are bigger, more complex & more uncertain items & these are included in a high-level plan. It is difficult to estimate them & hence vague or high-level estimates are used for these. On the Other hand, User Stories are more clear, simple & smaller items & easier to estimate & hence low-level estimates are used. These user stories deliver the MVP & set the velocity which further is used by stakeholders to plan & prioritize the direction of a complete product as per Market/Business value.