Tag: sprint

Shipping Daily : From Sprints to Continuous Releases

Nishi Grover GargLeave a comment

DevOps Teams that achieve daily releases have mastered a unique set of skills and practices to ship software faster and more frequently, with higher confidence. This high frequency release model differs significantly from the traditional Scrum framework with 2-week sprints (or longer). 

I wrote about this recently in my article published at devm.io platform , where I discussed the daily routines, processes and tools that support these teams, while contrasting them with more familiar cadence of traditional scrum teams. For teams and organizations looking to move towards daily releases, I also covered the key adjustments required to turn this vision into reality.

The Daily Rhythm: Planning, Execution, and Monitoring

1. Planning

For teams delivering code daily, the rhythm of planning, execution and monitoring does not follow the two-week sprint cycle but happens continuously. Here is what this daily rhythm looks like:

  • Frequent Prioritization: Daily release teams prioritize their work each day, selecting high impact tasks that can be completed and shipped within a single day.
  • Dynamic Backlogs: Instead of working with a static sprint backlog which is derived from the mammoth product backlog, these teams operate with highly flexible backlogs – adding things to it every day. They are ready to pivot quickly in response to customer feedback or issues, urgent needs or new business opportunities.
  • Smaller Targeted Tasks: Work items are broken into small, manageable pieces – each designed to be completed within hours. User stories and tasks are refined to be achievable in less than a day, keeping workloads manageable and ensuring that work completed aligns with daily release goals.

2. Execution

Unlike Scrum teams that often release at the end of a sprint, daily release teams execute work with a focus on immediate delivery.

  • Incremental Work: Instead of waiting until the end of a sprint, developers push small, frequent changes every day. Every code change is designed to be testable and deployable at the end of the day.
  • Automated Testing: It is critical to daily releases. CI pipelines are designed to run tests on each code change, ensuring stability and reliability and readiness of production.
  • Seamless Deployment: CD pipelines are in place, so that the code – once tested – is deployed automatically to production. With daily releases, teams cannot afford to spend hours on deployment activity every single day – so it is imperative to automate it.

3. Monitoring

  • Automated Monitoring: Monitoring tools track deployment success, system performance, and error rates in real time. Tools like Datadog, New Relic, or Prometheus help track application performance, error rates and system health. These tools are crucial for catching issues early and preventing them from impacting users.
  • Daily Retrospective Feedback Loops: Instead of waiting until the end of a sprint, the team reviews their daily progress and identifies immediate improvements – leading to quick adjustments.

Read the full article here for details on :

Normal Scrum vs Daily Release : Key Differences

Practices to Support Daily Releases

Key Metrics to Track

When are Daily Releases Appropriate?

Benefits of Daily Releases

3 Ways Technical Debt Can Actually Help Improve your Sprints

Nishi Grover GargLeave a comment

“Debt” is not a pleasant term. It brings to mind a burden and generates a feeling of anxiety. The same may also be true for technical debt, or the extra work that we incur while developing our software in the form of missed quality targets, pending tasks, or skipped points from our exit criteria checklists. Like monetary debt, technical debt happens when we make a decision that is quicker in the short term but will hurt us in the long term.

Though we may try our best to limit this debt, it will still happen. And while we will need to pay back the debt one day, we can also use it as a lesson to help improve ourselves and our processes. If it ultimately helps our development, it doesn’t even always have to be a bad thing.

In my article published on the Ranorex blog site, I examine three ways technical debt can actually help us improve our sprints.

Better Estimation

Though the first time incurring technical debt due to an inability to complete an activity as planned may not be pleasant, it should consequently improve the team’s estimation and planning.

Let’s say we had defined developers’ tasks for all user stories with estimated hours, along with a mandate of peer reviews being performed for all code being written. But the end of the sprint saw that though the developers marked their development tasks as done, none of the code had been peer reviewed before check-in. It could have happened due to lack of time or ownership.

The next sprint, the team then decides to have a separate sub-task for peer reviews under the development tasks, each of which is assigned to a peer with an allotted time of 30 minutes. This helps the team plan, have clarity around what tasks are pending, and see how much effort is being spent on the tasks.

So, even though you may begin to accumulate technical debt early on in your sprints, understanding the cause and having a plan of action may improve the team’s overall performance.

Sequencing and Prioritizing

If you find yourself at a point where release is a couple of sprints away and you have a number of unresolved defects, even though they are lower severity, the team may decide to reduce open defect counts for a sprint rather than adding new features. The technical debt incurred in the form of defects can urge the team to refocus and shift priorities.

Or, let’s say your team agreed to 70% automation of regression testing in the beginning of the release cycle, but after four sprints, the scripts they created are showing signs of being unmaintainable or not scalable enough. This may affect delivery in the end, so some testers may take the call of focusing full time on reworking the scripts and adding new automated tests to them, while the other testers take up functional and regression tasks.

My team once found out at the end of our fifth sprint that our developers had not been performing static analysis of their code or creating the reports that were mandated for every sprint. Whatever may have been the reason, this meant that running those reports now was leading to hundreds of errors or warnings all pertaining to code formatting, naming conventions and comments. Even though these were minor issues, it required time to get them all corrected with thousands of lines of code.

Read More »

Achieving the Goal of In-Sprint Test Automation

Nishi Grover GargLeave a comment

Getting test automation done is a challenge, especially within the tight deadlines imposed by Scrum. As much as the thought of continuous in-sprint test automation sounds enticing, the practicality of it may elude most Scrum teams.

In my article published here– I look at some of the main things you need to consider in order to get your test automation done within the confines of your sprint.

Framework

The first thing to focus on is a framework that is useful, is easy to understand, and helps all stakeholders participate in test automation.

This is essential because you want to make test automation a continuous activity that is a part of daily work, not a once-a-sprint (or once-a-release) work item. For this to happen, the framework must make it equally comfortable for a businessperson, developer, functional tester or automation expert to add their contribution and see the results of their efforts.

There are many business-friendly frameworks and techniques, like behavior-driven development (BDD), as well as many tools that can create tests in a domain language and then translate them to script code.

All stakeholders must be trained on using the framework, and their area of contribution must be made clear to them, with practical hand-holding. The automation tester can then focus on maintaining the framework, generating test suites and editing failing scripts, while the creation of test automation will be a continuous task assigned to everyone involved.

Collaboration

The next thing to focus on is collaboration between the various stakeholders. A continuous automation framework can only survive when it is being fed and tended to by everyone on the team.

  • The business people, like a business analyst or a product owner, can help by adding user scenarios or defining the requirements in a framework-friendly format. This may require them to be trained on the preferred format based on the framework being used
  • The developers can help by creating reusable methods for steps of the script. They can also create and maintain an object repository for all elements they add to the UI while testers use the pseudo names of the elements in the test scripts. This means that the scripts can be created before (and independent of) the application UI, and such scripts won’t need editing when the UI changes, as long as the object repository is kept up to date
  • The testers can help by adding more scenarios, specifying and creating test data, and executing the scripts periodically

Strategy

How to strategize the development of test scripts is crucial to making in-sprint automation a reality. Using API-level automation whenever possible will reduce the time and effort.

Continue Reading –>

Read More »

Defining Exit Criteria for different phases of your Agile project

Nishi Grover GargLeave a comment

Exit criteria are a list of items to check off that define the end of any activity. Exit criteria can be defined for any activity you want to undertake: You can have exit criteria for cooking veggies to the desired doneness, or for a city tour to be sure you see all the sights, or for a meeting to assign action items for everyone! Exit criteria are helpful to tell you (and others involved) when to stop the activity. Specifically, for an agile project, having clear and concise exit criteria makes it easier to understand the scope and avoid going overboard while keeping a tab on your quality. 

In my article published at Gurock https://blog.gurock.com/agile-exit-criteria/ , I have discussed some ways to structure your exit criteria at the sprint, user story, and task levels in an agile project.

The first rule for exit criteria is to have them defined up front, before beginning the activity.

For an agile project, let’s say we want to have exit criteria in place for the end of the sprint. We will need to work on defining them at the beginning of the sprint, or at the release-planning stage. Once the activity begins, the goal is to achieve all exit criteria by the end. We cannot have people defining or changing the planned exit criteria during execution of the activity, since that will not be upholding the quality standards set in the beginning.

The second rule is to have standard exit criteria for all similar activities. So, exit criteria defined for the sprint level apply to all sprints in that release, and exit criteria defined for the user story level apply to all user stories in all sprints. This upholds the same standard of quality and expectation of work required for each of these work units.

In the article, I have discussed sample Exit Criteria for Sprint, User Story or Task level and also shown how to create your own exit criteria based on your project’s and team’s context.

The important things to focus on are having the exit criteria defined up front and ensuring follow-through by sticking to the criteria throughout your release cycle. Being consistent with checking off everything on your exit criteria list ensures a smooth flow of high-quality work.

Check out the complete article here – >