Learning one new thing everyday
The INVEST as a reminder of the characteristics of a good quality Product Backlog Item (PBI) (or user stories) commonly written in user story format. But what are characteristics of a good user story? The acronym “INVEST” can remind you that good stories should be
Continue reading
Each sprint ends with a two-part sprint review meeting. Such a meeting starts with a customer review and demonstration and ends with the team retrospective. Both of these components occur on the last day of the sprint. The Sprint Review focuses on the “inspect” and “adapt” of the increment (Potentially shippable), while the Sprint Retrospective give more focus on the “inspect” and “adapt” of the process of the sprint.
Continue reading
Definition of Done (DoD) is a list of requirements that a user story must adhere to for the team to call it complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be met to confirm that the software is working as expected.
Continue reading
In the summer of 2011, Ken Schwaber and Jeff Sutherland revised their Scrum Guide. In it, they removed one long established behavior known to Scrum, which is the commitment the team makes to the product owner and the customers. Commitment was replaced by forecast. They say that teams may forecast their work, but not commit to it.
Continue reading
In software development , the usual “estimation” includes a quantitative evaluation of the work required to perform a given development task; this is usually expressed in terms of duration (hour / day) or estimated unit (story point). The purpose is to consolidate a number of such individual estimates in order to obtain an indication of the overall duration, work or cost of the software project.
Continue reading
We always come across these terms in software development. Sometimes people a piece of software feature — requirement/ use case, backlog items …. What is the convention of the software people for using that or which?
Continue reading
LeSS was created by Bas Vodde and Craig Larman from practical experience in scaling up Scrum, founded as the LeSS Company in 2014. The “More with LeSS” principle is at the heart of LeSS (Large Scale Scrum). Complex product development doesn’t require complex solutions. It requires a deep understanding of the essence of the problems, which can then be solved with simpler solutions.
Continue reading
Most Agile and Scrum training courses refer to a 7 +/- 2 rule, that is, agile or Scrum teams should be 5 to 9 members. Scrum enthusiasts may recall that the Scrum guide says Scrum teams should not be less than 3 or more than 9. Where does this thumb rule come from? and Why?
Continue reading
LeSS is a lightweight, Agile framework for scaling Scrum to more than one team. Starting in 2005 Bas Vodde and Craig Larman developed the LeSS framework after using Scrum principles and rules on large scale projects. Their goal was to develop large scale projects successfully while staying within the constraints of Scrum.
Continue reading
Agile development is a human-centric, iterative, and gradual development method. In agile development, the construction of a software project is divided into multiple sub-projects, and the results of each sub-project have been tested and have the characteristics of integration and operation. In other words, a large project is divided into multiple small projects that are interrelated but can also be run independently, and completed separately. During this process, the software is always in a usable state.
Continue reading