Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts

Sunday, May 21, 2017

Kanban-Vs-Scrum


What is Kanban
Kanban is Japanese for “visual sign” or “card.” It is a visual framework used to implement Agile that shows what to produce, when to produce it, and how much to produce. It encourages small, incremental changes to your current system and does not require a certain set up or procedure. Kanban is called the “pull system.” When looking at Kanban vs Agile, it’s important to remember that Kanban is one flavor of Agile. It’s one of many frameworks used to implement agile software development.
In the context, Kanban board is easy to learn and understand, it improves flow of work, and minimizes cycle time. The benefits of Kanban include:

  •         Increases flexibility: Kanban is an evolving, fluid model. There are no set phase durations and priorities are reevaluated as new information comes in.
  •          Reduces waste: Kanban revolves around reducing waste, ensuring that teams don’t spend time doing work that isn’t needed or doing the wrong kind of work.
  •          Easy to understand: The visual nature of Kanban helps to make it incredibly intuitive and easy to learn. The team doesn’t need to learn a completely new methodology, and Kanban can be easily implemented on top of other systems in place.
  •          Improves delivery flow: Kanban teams optimize the flow of work out to customers. Like continuous delivery (CD), Kanban focuses on the just-in-time delivery of value and delivering work to customers on a regular cadence.
  • ·         Minimizes cycle time: Cycle time is the amount of time it takes for work to move through the team’s workflow. In Kanban projects, the entire team helps to ensure the work is moving quickly and successfully through the process.
What is Scrum
Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one. A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework.
In the context, Scrum is a highly prescriptive framework with specific roles and ceremonies. While it can be a lot to learn, these rules have a lot of advantages. The benefits of Scrum include:
  •          More transparency and project visibility: With daily stand-up meetings, the whole team knows who is doing what, eliminating many misunderstandings and confusion. Issues are identified in advance, allowing the team to resolve them before they get out of hand.
  •          Increased team accountability: There is no project manager telling the Scrum Team what to do and when. Instead, the team collectively decides what work they can complete in each sprint. They all work together and help each other, improving collaboration and empowering each team member to be independent.
  •          Easy to accommodate changes: With short sprints and constant feedback, it’s easier to cope with and accommodate changes. For example, if the team discovers a new user story during one sprint, they can easily add that feature to the next sprint during the backlog refinement meeting.
  •          Increased cost savings: Constant communication ensures the team is aware of all issues and changes as soon as they arise, helping to lower expenses and increase quality. By coding and testing features in smaller chunks, there is continuous feedback
Scrum vs Kanban:
Scrum and Kanban are both flavors of Agile, but they have some distinct differences.
  • Scrum requires specific roles whereas Kanban has no required roles.
  • Scrum board is reset after each sprint. A Kanban board is continuously used.
  • Scrum is based on time boxed iterations, combining planning, process improvement, and release. In Kanban, you can choose to do these activities on a regular cadence or whenever you need.
  • Scrum limits work in progress (WIP) in each iteration, whereas Kanban limits WIP in each workflow.
  • Scrum resists change, whereas Kanban easily accommodates and embraces change. In Scrum, once the team has committed stories to a sprint, you can’t add additional stories later on. In Kanban, you can add or change stories as you please, assuming that it’s within WIP limits.
  •  A Scrum team is cross-functional and one team owns the Scrum board. In Kanban, teams don’t need to be cross-functional and anyone can own the Kanban board.
  •  Estimation forms the basis for Sprint Planning in Scrum whereas Kanban is a continuous model of delivery, so estimation doesn't hold significance.
And Scrum and Kanban also have some similarities: 
  •          They are empirical. You have to experiment with the process to see what works for you.
  •          They are Lean and Agile.
  •          Both allow team members to work on multiple products at once.
  •          They both limit WIP (although the way they each limit WIP is different)
  •          They use pull scheduling
  •          They focus on delivering software early and often
  •          Both use transparency to improve process
Scrumban:
Scrumban combines the principles of Scrum and Kanban into a pull-based system. The team plans out the work that was established during initiation and continually grooms the backlog. The same Scrum meetings should take place, but the frequency can change depending on context and need. The most important part of Scrumban is making sure that work in progress limits (WIP limits) are followed.

Scrumban takes bits and pieces from both Scrum and Kanban. For example, it includes the defined roles, daily Scrum, and other meetings from Scrum. And from Kanban, it takes the Kanban board, continuous flow, and ability to add changes as needed to the board.

Scrumban can look more like Scrum on the technical level, but at the cultural level, it will more closely resemble Kanban. Instead of big changes all at once, Scrumban encourages incremental changes. If your team is looking to migrate from Scrum to Kanban, Scrumban can provide a gentle transition.

Which One Is Best?
When comparing Kanban versus Scrum, there is no definitive winner. The best framework depends on your project, team, and your goals. Because both Kanban and Scrum are flexible agile methodologies, you could easily take principles from each and apply them as you see necessary.

It’s important to remember that true Scrum is a much bigger shift than Kanban. The team will have to learn about the ceremonies, the specific roles, and iterations. On the other hand, Kanban encourages incremental improvements. You can apply Kanban principles to any process you already have in place, even Scrum. Nothing needs to change significantly to get started with Kanban…

Courtesy: Several online blogs, Books & other resources,Image Credit to "Grow"

Tuesday, April 12, 2016

Backlog Prioritization

Let's start with Agile Manifesto, it says
  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan
Where there is value in the items on the right, we value the items on the left more.  Reason is simple Agile focuses on Kaizen (Continuous Improvement), which is a strategy where employees at all levels of a company work together proactively to achieve regular, incremental improvements in the product.
Backlog grooming or refinement is the process which focuses on   Continuous Improvement on the product being developed.
What is product backlog refinement?
Product backlog refinement is the process through which product backlog items are reviewed by the Scrum team and revised, providing more detail and ensuring that there is greater clarity in the requirements for that item.
What product backlog items should be refined?
Any product backlog item should be refined as and when additional information is known about it. However, priority should be given to refining the product backlog items that are likely to be taken into the next sprint. This will ensure that enough information is known about each item to allow for it to be sized, for the plan to be generated during sprint planning as to how the selected product backlog item can be delivered, and to allow for the team to commit to delivering that and other items in the next sprint.
When should product backlog refinement take place?
Product backlog refinement should be an ongoing process. However, some teams find it useful to have a planned mid-sprint session that allows for product backlog items that are candidates for the next sprint to be discussed.
There are several ways to prioritize the requirements in the backlog. Some of the most popular ones include
1.     MoSCoW
M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not affect anything else.
W - WON'T have this time but would like in the future.
Each requirement will have the priority which would be tagged to MSCW. "M" being the highest and "W" being the lowest.
2.   Business Value Based
In this case, each requirement carries a business value it could potentially generate to the company. The business value would be decided either by the Product Owner or the Product owner team.
The requirement with highest business value is implemented during earlier releases.
3.   Technology Risk Based
In this method, requirements are prioritized based on the risk associated in implementing it. The risk is typically based on the technology.
The requirement with highest technology risk is implemented during the earlier iterations. 
4.   Kano Model 
In this method, the requirements are prioritized based on the customer preferences. Mr. Noriaki Kano developed Kano model as valuable technique helping to recognize that. Applying this method the product owner can identify importance of stories by asking questions like these:
Is the feature mandatory? We will not earn additional revenue once we have it but without it the product doesn't fulfill existence principles.
Having a feature, will customer say: "Hey, that's nice! I like this approach and it seems to be really helpful." This feature is excitement. It is possible differentiator.
Well, guys improved a performance of the application. This is valuable.  Comparing to other products, this product is one I would like to use.
Hmm, this feature is indifferent. It doesn't matter if this feature is or is not implemented. If vendor provides it, ok, I accept it. If it's not implemented, no problem then.
This feature is really questionable. I am not sure if I am going to pay for product with such feature. It'll probably slower me. Also, I assume it will complicate usability in my company. Let's think about different product.
Ohhh no! Not the feature like that. You are kidding. These features reverse me to really find a different product. Such perspective is great way to identify priorities in complex backlog.
  • Attractive
  • One-Dimensional
  • One-Dimensional
  • Must-Be
  • Indifferent
  • Reverse

5.    Walking Skeleton 
In this method, the requirements are selected such that minimal carefully selected end to end features are built within a short span of time.

6. Validated Learning 
In this method, features are chosen based on the highest market risk i.e. something that is not experimented yet. Release it to the market, get the feedback and apply the learning onto the new feature
In this blog I covered basic definitions of Backlog Prioritization techniques ,  I would suggest please refer several blogs and eBooks available out there on internet for more details.

Please let me know you inputs, Suggestions or questions on this.

Courtesy: several online resources i.e. Blogs, Tutorials etc.