Agile Velocity is an extremely simple method for measuring the rate at which scrum teams consistently deliver business value. In other words – How much product backlog effort a team can handle in one sprint? It’s the rate at which a team delivers stories from the product backlog, i.e. sum of estimates of delivered (i.e., accepted) features per iteration. It can be measured in story points, days, ideal days, or hours that the Scrum team delivers – all of which are considered acceptable.
This is one of the most common questions discussed among the Agile Community – What happens with the undone User Story of Current Sprint? Why does this happen? How should you deal with the undone user story? What should become of such stories? What should be done with the product backlog item itself? Should be it split or should it be carried into the next sprint? Should the team receive any velocity “credit” for completing a portion of the story? And how do you prevent it from happening again? This article addresses all of these questions.
Agile software testing is the requirement of a modern software development team. Choosing agile testing tools is not an option anymore, it’s a necessity. If you want the end product to be effective, speedy and sustainable simultaneously, you must go with a tool which provides agile testing solutions under a feasible budget.
Definition of done is one of the Agile fundamental things. Yet many teams do not see its importance or are unsure what Definition of Done actually is. The term is also often confused with the acceptance criteria, leading to mis-communications and false expectations. So, let’s have a look at this important agile concept – the definition of done.
Today most of the organizations are moving or have already moved to agile development and testing. Or at least they think so. Sprints and daily stand-ups are common. Everybody is talking about Scrum & minimum viable product. We are tracking the team velocity & burndown. We have cut down on the documentation & invested in working software. Everyone is focused on customer satisfaction by accepting change. But wait a minute! This is too-happy a picture to be true.
For more than a decade now, Agile Project Management has been used and it wonderfully continues to grow in popularity. It is one effective methodology introducing revolutionary methods for the practice of project management. ‘Agile’ is an umbrella term used for identifying various models used for agile development, such as Scrum. Since agile development model is different from conventional models, agile project management is a specialized area in project management. It is required for one to have a good understanding of the agile development process in order to understand agile project management.
Velocity: “the speed of something in a given direction.” And how do you measure it while driving? How do you know that your average velocity is 80 km per hour if you have traveled 160 kilometers in 2 hours’ time? I.e. kilometers traveled in one hour. The same goes for an agile project. Agile Velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. This article explains the principles behind agile velocity tracking.
User stories and Use cases are both used to document the requirements. They both capture features of the system. They’re both used by the development team to construct the best solution. They can be used to organize and categorize requirements. And they can be used as references during testing to ensure that the requirements have been met. While user stories and use cases are similar, they also differ in substantial ways. The difference can be challenging to understand and explain, especially if your team is making a transition from a Waterfall software development environment to Agile and Scrum. Each serves a distinct purpose, and they both have their place on a well-run software project. We will try and cover User story vs Use case in this article…
A burndown chart is a graphical representation of work left to do versus time. It is very simple, easy to explain and understand. It is often used in agile software development methodologies such as Scrum. However, burndown charts can be applied to any project containing measurable progress over time. Outstanding work can be represented in terms of either time or story points. When tracking using the Burndown chart, teams can use a sprint Burndown chart and a release Burndown chart. It is one of the most important artifacts and a fundamental metric in agile scrum.
Simply stated – Within an agile development project, the Sprint Backlog is a document that lists the tasks to be performed as part of a Sprint. During Sprint Planning Meeting, the User Stories, which are approved, estimated, and committed, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.
Scrum, the most popular agile framework in software development, has at its core the agile sprint — the scrum term for iteration. It is a short, consistent cycle no longer than four weeks. The goal is to have an iteration short enough to keep the team focused but long enough to deliver a meaningful increment of work. The agile sprint begins with Planning and ends with Review & Retrospective. Each day of the Sprint is marked by a brief meeting called the Daily Scrum or simply, Stand-up.
Most of the projects today follow Agile methodology, and Scrum in particular. One of the four agile values say ‘Working software over comprehensive documentation’ – but it doesn’t mean NO documentation. It simply means only ‘effective’ documentation. We as testers are familiar with User Stories, the next most important & effective agile documentation is the Product Backlog. In this article let’s get a clear understanding of what is a Product backlog and its importance in agile implementations!
A good product backlog is at the heart of any well-functioning agile team. It does not automatically guarantee a quality software. However, the lack of a good product backlog often results in incomplete software that does not meet the requirements of your customers and stakeholders.
If you don’t get the user needs right, it doesn’t matter how well you execute the rest of the project. Requirements are the foundation for all the project work that follows. The software development project success lies in understanding the user requirements accurately and appropriately, and then implementing them in the final product. The purpose of a software project is to build a product that provides value to its customers. Thus customer involvement is the most critical contributor in eliciting requirements. Prior to agile, software requirements were described with respect to system. Though not bad, but still there was less user interaction or requirements were not formulated (in detail) from User perspective. The result – industry adopted a new standard. You might have heard about User Story in Agile Software development projects. In this article, let’s see what does User Story actually mean!
Kanban Agile is one of the most popular software development methods adopted by agile teams today. But did you know the Kanban method of work dates back more than 65 years? That the idea for Kanban was originally inspired from a Supermarket? Or that its application started from the production systems? Only recently many thought-leaders in various industries have found its applicability beyond the manufacturing industry as well, including Software delivery. This article provides a comprehensive overview of the Kanban Agile method.