Search

Scrum vs Kanban: Deciding The New Agile Benchmark

Today in the rapidly changing market, software development is changing its list of requirement every now and then. As we all know, Agile is one form of software development methodology which mainly focuses on the continuous delivery of project with client satisfaction. Agile always accepts the change and works on complete specifications to turn the project into a deliverable product.In the recent times, Kanban software development methodology is in the limelight for its ability to enable DevOps. Many of the organizations are moving from Scrum to Kanban for better results. So the question arises, which Agile methodology works better?And  Scrum vs Kanban becomes the essential question today. The key differences between Kanban and Scrum depend on the rules for using the Scrum methodology and the Kanban workflow.When the organization implements any methodology which is not flexible and useful, this can make the organization inefficient. This leads to the introduction of an Agile methodology in the organization. So, the first step while implementing the Agile methodology in the organization is to decide which Agile framework will be the best for you and your team.Suppose, you have chosen a Scrum framework and Kanban workflow, then what is the difference between Scrum and Kanban? Is Kanban Agile? What is Scrum vs Agile? And so on.GOLDEN RULESBoth Scrum and Kanban have a list of mandated and optional rules for their implementation. According to the Agile advice list for implementing Scrum, there are around 23 mandatory and 12 optional rules. Here are the few examples:Teams are functioning in a  cross-functional mannerDuring sprints, Interruptions are strictly avoidedWork is always time boxedScrum meetings are held on a daily basisTo measure the progress a burndown chart is usedFirstly, the problem arises when organizations follow “Scrum-But”- which is basically ignoring some specific set of rules for internal reasons. The next issue arises with timeboxing, which forms the core of Scrum. It allows the developer to define milestones for the Stakeholders to evaluate and guide their project.Now, in the case of Kanban, the rules are comparatively less restrictive. The principal rules are-Limiting the work in progressTo Visualize the workflowKanban is a flexible and an open methodology that can add rules as needed, borrowed from Scrum depending upon the requirement. In Kanban, the focus is mainly on the flow and not on the timebox. This feature makes Kanban a very appealing choice to use with DevOps.WORKFLOW METHODOLOGYFor Scrum:If we take the case of Scrum, every feature is decided before and it is ensured that it will be completed by the next sprint. After that, the Sprint is locked and work is finished over a couple of weeks, that is, usual sprint duration. The locking of the sprint is done to make sure that the team is getting enough time to make last minute changes depending on the requirement. There is a feedback session for reviewing the work accomplished. This helps to ensure that the delivered amount of work is approved by the stakeholders and is enough for directing the project as per business requirement.Implementing Scrum is not as easy as learning its principles. It requires to change the team members’ habits. The team members have to raise the quality of coding, take up more responsibilities, increase a speed and many more factors need to change. Scrum allows team commitment as the team commits to the Sprint goals, they always stay motivated to get better and fast results as per the user requirements.  For Kanban:In the case of Kanban, the priority is to focus on the workflow and not on the time. The limitation is only regarding the size of the queues. The main aim behind implementing Kanban is the productivity and efficiency of the product. This allows them to deliver superior quality work items. In addition to this, concentrating on the workflow will keep things moving. In Kanban, there is an extended feature known as stakeholder participation.In Kanban board, it is mandatory to define a “Work-In-Progress-Limit (WIP Limit)”. This helps to know the status of the work items to be delivered. If a status reaches the fixed WIP-limit, no new task is allowed at that state. This board helps to resolve the bottlenecks, as it makes the progress visible for further improvements. So, these WIP Limits acts as a change agent in Kanban.The Workflow of the KanbanComparison of Scrum and KanbanScrum vs Kanban: Deciding between the duosIf your team is responsible for enhancing the feature development feedback of the Stakeholder, then go for Scrum. But, if your team is in charge of maintenance and requires to be more reactive, you have to consider Kanban. Eventually, the need for every team is different and depending upon the requirements, methodologies need to be decided for the achievement of the goals.
Rated 4.0/5 based on 35 customer reviews

Scrum vs Kanban: Deciding The New Agile Benchmark

2K
Scrum vs Kanban: Deciding The New Agile Benchmark

Today in the rapidly changing market, software development is changing its list of requirement every now and then. As we all know, Agile is one form of software development methodology which mainly focuses on the continuous delivery of project with client satisfaction. Agile always accepts the change and works on complete specifications to turn the project into a deliverable product.

In the recent times, Kanban software development methodology is in the limelight for its ability to enable DevOps. Many of the organizations are moving from Scrum to Kanban for better results. So the question arises, which Agile methodology works better?

Scrum saying
And  Scrum vs Kanban becomes the essential question today. The key differences between Kanban and Scrum depend on the rules for using the Scrum methodology and the Kanban workflow.

When the organization implements any methodology which is not flexible and useful, this can make the organization inefficient. This leads to the introduction of an Agile methodology in the organization. So, the first step while implementing the Agile methodology in the organization is to decide which Agile framework will be the best for you and your team.

Suppose, you have chosen a Scrum framework and Kanban workflow, then what is the difference between Scrum and Kanban? Is Kanban Agile? What is Scrum vs Agile? And so on.

Scrum vs Kanban
GOLDEN RULES

Both Scrum and Kanban have a list of mandated and optional rules for their implementation. According to the Agile advice list for implementing Scrum, there are around 23 mandatory and 12 optional rules. Here are the few examples:

  • Teams are functioning in a  cross-functional manner
  • During sprints, Interruptions are strictly avoided
  • Work is always time boxed
  • Scrum meetings are held on a daily basis
  • To measure the progress a burndown chart is used

Firstly, the problem arises when organizations follow “Scrum-But”- which is basically ignoring some specific set of rules for internal reasons. The next issue arises with timeboxing, which forms the core of Scrum. It allows the developer to define milestones for the Stakeholders to evaluate and guide their project.

Now, in the case of Kanban, the rules are comparatively less restrictive. The principal rules are-

  • Limiting the work in progress
  • To Visualize the workflow

Kanban is a flexible and an open methodology that can add rules as needed, borrowed from Scrum depending upon the requirement. In Kanban, the focus is mainly on the flow and not on the timebox. This feature makes Kanban a very appealing choice to use with DevOps.


WORKFLOW METHODOLOGY

For Scrum:

Scrum board

If we take the case of Scrum, every feature is decided before and it is ensured that it will be completed by the next sprint. After that, the Sprint is locked and work is finished over a couple of weeks, that is, usual sprint duration. The locking of the sprint is done to make sure that the team is getting enough time to make last minute changes depending on the requirement. There is a feedback session for reviewing the work accomplished. This helps to ensure that the delivered amount of work is approved by the stakeholders and is enough for directing the project as per business requirement.


Implementing Scrum is not as easy as learning its principles. It requires to change the team members’ habits. The team members have to raise the quality of coding, take up more responsibilities, increase a speed and many more factors need to change. Scrum allows team commitment as the team commits to the Sprint goals, they always stay motivated to get better and fast results as per the user requirements.  

For Kanban:

In the case of Kanban, the priority is to focus on the workflow and not on the time. The limitation is only regarding the size of the queues. The main aim behind implementing Kanban is the productivity and efficiency of the product. This allows them to deliver superior quality work items. In addition to this, concentrating on the workflow will keep things moving. In Kanban, there is an extended feature known as stakeholder participation.

In Kanban board, it is mandatory to define a “Work-In-Progress-Limit (WIP Limit)”. This helps to know the status of the work items to be delivered. If a status reaches the fixed WIP-limit, no new task is allowed at that state. This board helps to resolve the bottlenecks, as it makes the progress visible for further improvements. So, these WIP Limits acts as a change agent in Kanban.

The Workflow of the Kanban

Comparison of Scrum and KanbanComparison of Scrum and Kanban

Scrum vs Kanban: Deciding between the duos

If your team is responsible for enhancing the feature development feedback of the Stakeholder, then go for Scrum. But, if your team is in charge of maintenance and requires to be more reactive, you have to consider Kanban. Eventually, the need for every team is different and depending upon the requirements, methodologies need to be decided for the achievement of the goals.

KnowledgeHut

KnowledgeHut Editor

Author

KnowledgeHut is a fast growing Management Consulting and Training firm that is a source of Intelligent Information support for businesses and professionals across the globe.


Website : http://www.knowledgehut.com/

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Use Cases: How Are They Different From User Stories & How To Create Them

I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opinion and knowledge by adding some comments at the end of this article. If you don’t know why I consciously mentioned “create” instead of “write” then worry not. I will share my thoughts  with you and you can tell me what you think and let’s create a dialogue around it. In my previous article, I had written about user stories, and how they came into extensive usage, how they help develop better products and how they represent users’ voice at forums users don’t have access to. If you have not read that article then I would sincerely request you to read that article first as it will immensely help you in getting the right perspective about this topic at hand. Use cases in simple words are exact statements written in informal manner depicting the specific action that the user is expected to do while dealing with a particular functionality of the product. If you compare this with the definition of user stories I gave in my previous article, you will notice that here I have defined use cases as “exact statements” whereas I had defined user stories as “generic statements” written in informal manner. Why? This is because user stories set a foundation upon which great use cases are created or developed. While user stories try to explain to the engineering team about the environment, goal, role, intention of the user while he/she is going to deal or work with the software; use cases clearly define what the user is going to do here and what result is expected in crisp 2-3 lines. Use cases are one level above requirements. Below is a simple table for quick reference on differences between user stories and use cases. A simple example of creating use cases from user stories: Let us take a very simple example of a toothpaste and let’s create use cases out of it. If you want to see how to develop user story then please read my earlier article on user stories. Always remember, while it will seem easy to create use cases directly from user needs; it is full of pitfalls that might lead to missed functionality and user dissatisfaction later on, after shipping the product. So a user story would look somewhat like this: Actor  :    John, a working professional who wants to keep his teeth health and shiny Role    :    The direct consumer of this product but can influence others by his reviews of a product on his website. Expected results: After brush, John expects his breath to be fresh and teeth and gums to be health for the whole day. Now as you can see, John is a very high impact user for us [The toothpaste company] because he can affect our sales by his review of our product on his website. So meeting his needs are very critical for us. Hence the product manager, should create following user story for this scenario. Sample User Story: It is 6:30AM in the morning and John has started his morning rituals to be ready for work. Daily, his first routine after waking up is to brush his teeth with his favorite toothbrush so that he gets the refreshing feel to do remaining chores around the house and leave for work on time. He likes the way toothpaste, smoothly oozes out of the tube and rests firmly on this toothbrush without spilling anywhere. Also he likes that somehow, every time he brushes, the exact right amount of the paste comes out of the tube. It is never too much and never too little. It’s just right. He feels energized after a refreshing brush ritual and likes the feeling of freshness in his mouth after brushing his teeth. His gums feel rejuvenated, breath feels fresh as he tests it out on his palms. After spending whole day at office, where he had multiple cups of coffee, some food and some sugary items, he comes back home. While refreshing himself, he notices that his breath is still fresh and the taste in his mouth is still neutral without any traces of coffee or cheese pizza he had before. He is so pleased with the product that he has bought for himself, that he decides to write about it in his blog tonight. Now let us create some use cases out of the above user story. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Use case 4: User feels an air of freshness in his mouth after brushing and that freshness lasts for minimum of 24 hours. The feeling of freshness is neither overwhelming nor un-noticeable. It is just mild   enough to provide a feeling of freshness while not interfering with user’s culinary habits. Use case 5: The user is pleased with the fact that the teeth and gums feel very smooth and non-scratchy after every brush. Use case 6: User is happy about the fact that even after 12 hours of intense work day routine, his breath still feels fresh And so on and so forth.  Can you think of some more use cases? If yes, do leave your comment below so that we can discuss on their validity and applicability here. Is the concept of use cases starting to make itself clear to you now and how they are different from user stories? Let us try once more. This time let us try to create use cases of this same product but for different customer base. Sample 2 of creating use cases for a product: This time, instead of a working professional, John. Let us consider Alayah, a teenage girl in high school. Actor :    Alayah, a 16 year high school student who is interested in experimenting new things with regards to body hygiene for better well-being and feeling. Her opinion is slightly influenced by the           feedback of her friends and her own personal experiences as she too likes to share her feedback with them. Role :    A direct consumer of our product and her feedback can motivate others in her circle of influence to try out our product. Expected Results: While healthy teeth and gum are the most basic of her requirements, she is bored with the same tasting toothpastes on offer these days. She wants to try out a new toothpaste that     not only provides her with best dental protection but also convinces her Mom of her ability to choose different but a better product by herself. Here, our engineering team’s task is clear. They need to create a product [toothpaste in this case], that not only impresses Alayah but also provides her with the best dental protection that she needs at her age. Her feedback carries the possibility of our product’s adoption by her immediate family members and her close friends, hence opening the market for us. The product should be unique in itself while being the best in terms of quality at cost effective price, since Alayah is not an earning member of her family. A product manager in this case, will have lot of options to think of a product here and specify to the engineering team. Let us go with one of them. Do share your versions of user stories in this case. User story: It’s morning time and Alayah’s alarm is ringing she had set last night to wake her up on time, if she needs to make it to the school without being reprimanded. She quickly jumps into the shower with a toothbrush having toothpaste on it, while her favorite song is playing out on her personal stereo. While she is freshening up, she is delighted with the fact, even after so many days, her toothpaste continues to give out the same wonderful strawberry flavor that she loves so much. And to add to her delight, her dentist gave her a big thumbs up yesterday on her teeth and gum health. Alayah has been using this toothpaste for a month now and she loves the way, the tube feels like new everyday even after so many uses. She never has to squeeze hard to get the paste out of it. One gentle squeeze and strawberry colored toothpaste gently but firmly oozes out of the tube and rests on the bristles of the brush. Earlier, she used to get lot of scolding from her mother on spilling the paste around the sink, while jumping into shower with toothbrush and paste on it. But ever since, she switched to this new toothpaste, there has not been a single spill ever since. Today, she is definitely going to tell her Mother to make permanent switch to this paste. She will recommend the butterscotch flavor to her Mom because she loves it. Wow! A wonderful experience of morning ritual for Alayah’; isn’t it? Let us create use cases for this one. Use case 1: User is delighted with the fact that tooth paste comes in a flavored version and the flavor of the paste is consistent throughout till the last drop in the tube. Use Case 2: User is experiencing a natural growth in well-being of her gums and teeth due to the regular usage of toothpaste and is certified by her dentist also. The noticeable difference comes out in 1 month of regular usage. Use case 3: The user is happy about the quality of the product and feel of it. The flow of the paste is smooth, uniform and consistent. It is firm yet soft to the right degree and grips the bristles of the       brush firmly without leaving behind any residue. Use case 4: The user is happy with the non-slipperiness of the paste as it holds wells on the toothbrush without spilling on to the floor. Use case 5: The user is going to recommend the product to her family members owing to its cost effectiveness, quality of results and number of flavored options available to choose from. In this case, the product manager’s diktat was clear. The toothpaste should be premium feeling with right amount of firmness, variety of flavored options to choose from, health improving and certified. And how did we learn properly? Because we were able to create user stories and use cases properly depicting the right user environments, their interactions with the system and their expected goals from these interactions. This is how use cases add value to the development of right product whether it is software based or manufacturing based or service based. So next time, when you want to ship to the customer, make sure you have all the right user stories targeting the right audience with complete use cases and your product will be a smash hit. This is why, I said, a product manager “creates” use cases and does not merely “write” them. Because while creating use cases, the product owner gets the feel, intent of the product that will surely be missed out if he/she is merely jotting down the requirements or use cases. In my next article, I will share with you on how requirements come out of use cases. Until then, happy creating user stories and use cases and do share your experiences with me on my email or in the comments’ section below. Thank you for your time!  
Rated 4.0/5 based on 20 customer reviews
Use Cases: How Are They Different From User Storie...

I could have used the word, “write” instead of... Read More

SAFe® Agilist Certification Vs PMI-ACP®: Which Certification Should You Choose?

The competition for jobs is getting tough in today’s world. Whether you are a job seeker, corporate employee, or a consultant, you should keep your skills up to date in a fast-paced, online world. Agile has become the standard of project management very fast in today’s world, specifically in the IT and service field. Most of the project management professionals have adopted Agile techniques, tools, and concepts to deliver the projects successfully that has never been seen before.If you want to make a career in Agile or want to make a career shift then Agile certification can be an added advantage. You might be in confusion as to which certification you should do, as there are different types of Agile certifications available. SAFe® Agilist and PMI-ACP® are the two most in-demand IT certifications today that will increase your career growth and salary.  In this post, we will discuss both the certifications and help to choose a career that best suits you.SAFe® AgilistLarger organizations are struggling with Agile, especially the well-established enterprises who are trying to adopt Agile and shift their way of doing things. SAFe® is one such example that provides best practices for adopting Agile at an organizational level and SAFe® certification covers every aspect of Agile from architecture, governance, funding, integration, and roles. Holding a SAFe® certification proves your proficiency and hands-on experience and shows your knowledge and skills in real-time implementations.SAFe® Agilist could be a perfect choice for you if you want to be part of different teams in the adoption of SAFe® and willing to be part of enterprise Agile. Scaled Agile is something different to standard Agile knowledge which is required for Agile change agents, managers, and executives for leading a lean-agile change initiative in large-scale enterprises. This is also essential for those executives who have already implemented Agile principles and practices at small-scale enterprises and now want to take it to the next level.Leaders of Lean-Agile change initiative can learn how to build a Lean-Agile Mindset and implement the SAFe® principles and practices to support Agile Teams, Program Portfolio Management, and Teams from this SAFe® 4 Agilist (SA) course. SAFe® Agilist certification demonstrates your efficiency of leading the Scaled Agile Framework adoption in an enterprise context.PMI-ACPPMI-ACP® certification could be an ideal choice for those who have been applying Agile values and principles in their day-to-day project work and who want to shift to a leadership role. To apply for  the PMI-ACP® certification, applicants must have at least 2,000 hours of working experience on project teams and 1,500 hours of working experience with Agile methodologies or on Agile project teams. Applicants should also complete 21 hours of Agile training and need to pass the exam.The PMI-ACP® is close to the mid-level CSP that is offered by the Scrum Alliance. Enterprises that are shifting to an Agile context and applying different Agile techniques are more interested in recruiting individuals with PMI-ACP® certification.PMI-ACP® could be a right choice if your enterprise is looking forward to adopting Agile framework in order to achieve high-end project goals. It not only covers Scrum framework but also includes XP, Kanban, Lean, and other frameworks. The PMI-ACP® certification exam is more difficult when compared to the basic Scrum Master certifications and individuals must take online or classroom training before going to attempt the exam.Let’s see the key differences between SAFe® Agilist and PMI-ACP®:It is important to look at the career opportunities before selecting the particular course. Think of various factors such as job security, responsibility, stress, income, and other benefits while choosing a profession.Just choosing a certification that is best for you doesn’t lead to the success you deserve. Choosing the best training provider will have a huge impact on the effectiveness of a course. Compare course outlines of different institutes and find the best training provider that will guide you in the right direction of the particular course chosen. You can also visit the institutes and attend some of the demo sessions to understand their approach to training. KnowledgeHut is a Registered Education Provider and offers both SAFe® Agilist and PMI-ACP® training classes across the country by experts who have years of industry experience.
Rated 4.0/5 based on 61 customer reviews
SAFe® Agilist Certification Vs PMI-ACP®: Which C...

The competition for jobs is getting tough in today... Read More

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a , I must be able to so that I can .  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Rated 4.0/5 based on 1 customer reviews
1632
Writing Effective User Stories in JIRA

User stories are one of the main methods of commun... Read More