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.
From the time I am blogging, it makes sense to me to pen down my sudden thoughts. Many a times you come up with an idea, memory, solution, problem, anything and it is lost since we don’t remember it in future. That’s when I started writing my sudden thoughts about Software Testing and guess what, the ‘Sudden Thoughts of a Software Tester’ is getting a lot of traction on my Social profiles. So thought of sharing it with you all. Here we go…
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.
There is no such statement as ‘I am now prepared for the interview‘. When facing a Testing interview no matter how many interview questions and answers you have gone through – there is always more to read ? Continuing on our Testing Interview questions series, let’s see some more interesting FAQs…
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.
There is no such statement as ‘I am now prepared for the interview‘. When facing a Testing interview no matter how many interview questions and answers you have gone through – there is always more to read ? Continuing on our Interview questions series, let’s see some more interesting FAQs…
Software Testing Levels, Test Data, Waterfall methodology, Agile Scrum, HTML Elements, Selenium Automation, WebDriver, Test Data Management, Scrum methodology
There is no such statement as ‘I am now prepared for the interview’. When facing a Testing interview no matter how many interview questions and answers you have gone through – there is always more to read 🙂 Continuing on our Interview series, let’s see some more interesting FAQs about,
HPE UFT automation…ETL & Data warehouse testing…Service-oriented-architecture…Test Management…Mobile Security…SOAP UI…Waterfall methodology…
Waterfall Methodology for Software development, introduced in 1970 by Winston Royce, is the pioneer of the SDLC processes. In fact it was the first model which was widely used in the software industry. Despite many new models being introduced, the Waterfall methodology is still the dominant process model. Additionally it is important to learn the know-how of Waterfall model in order to fully understand the emergence of Agile development methodology.
Transitioning to Agile? Or looking for ways to improve your current agile practice? These 12 Agile Manifesto Principles are a set of guiding concepts.
Many Software development methodologies evolved over the years, but why do you think Agile development stuck? What made it so popular? Yeah, the Foundation! The Agile Manifesto was written in February of 2001 by seventeen independent-minded software practitioners. The Manifesto defines four Agile values and twelve principles which forms the foundation of the agile movement.
“The art of life is a constant readjustment to our surroundings” – being Agile! Let’s see why Agile Methodology is not just an approach, it’s an attitude.