Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Overcoming DevOps Cycle Challenges by  Using Smaller Tasks, Getting Feedback Earlier

Receiving and improving on feedback is one of the core practices in DevOps cycle. According to the State of DevOps report, companies with shorter feedback cycles are identified as higher performing. When you receive important feedback too late, you’re hit with all sorts of issues with deployment, production, and customer feedback.  By delivering smaller batches, you can get more focused feedback on a faster timeline. 

Here are a few tips for making the most of your feedback cycle:

Practice Smaller Tasks

Let’s practice creating smaller tasks with an example. We have an online store and envision this feature, so we create a task:

Clearance Sales:

If our inventory has old stock, automatically create clearance sales on our website.

Reduce the price depending on the age of the stock.


How can we split this up? A good guideline is INVEST:

  • Independent: Make the task as self-contained as possible, with no dependency on another task.
  • Negotiable: Leave space for discussion and changes after feedback.
  • Valuable: Provide value to the stakeholders.
  • Estimable: Be able roughly estimate its size. It shouldn’t be open-ended.
  • Small: The task should ideally be able to be completed in hours or a few days.
  • Testable: Provide the necessary information to make testing the task possible.

Given these guidelines, think about how the feature can be split up into tasks. Here is my attempt:

  • Create a prototype. Emulate the feature manually by adding a hard-coded clearance sale on the website.
    Motivation: We can quickly see if customers are interested in the feature.
  • A task to develop the database tables and queries to find the right items for a clearance sale. Hardcode the price reduction.
    Motivation: We can deploy this, ensuring the database changes do not cause issues in production. We also specified that the price reduction is initially hardcoded, reducing the task complexity.
  • Provide REST endpoint for clearance sale.
    Motivation: We can deploy this and test it in production without customers using it.
  • Create UI for clearance sale, hide behind feature flag.
    Motivation: We might enable it for our team and some customers
  • Release feature for everyone.


By breaking it up into smaller batches of work, we can notice bugs in production and have a smaller change log to find where the issue could be.

Avoid Planning Too Far Ahead

If you create tasks for months to come all for a large feature, you lack the flexibility to pivot based on the feedback you receive along the way. Create only the tasks focused on your most immediate needs, otherwise you run the risk of wasting your time or backing yourself into a corner.


For example, after we deployed our prototype, we found that customers preferred an actual search filter over a single sale. When we updated the feature accordingly, we noticed a fixed price reduction was good enough, eliminating the need to develop a dynamic price reduction.


Another example is with the Apple M1 MacBook.  They took incremental steps towards it over the years, beginning with fat-binaries from Power-PC/Intel transition before progressing to using the ARM in the iPhone. From there they took small steps such as building their own chips and continuously improving them until they were able to be integrated into laptops.  Each step gave them an opportunity to gather feedback and improve their designs.




‘‘In the technology value stream, we often get poor outcomes because of the absence of fast feedback. When feedback is delayed and infrequent, it is too slow to enable us to prevent undesirable outcomes.’’ G.Kim, J.Humble, P.Debois, J. Willis. The DevOps Handbook. 


In software development we have the luxury that we can easily split up work into smaller tasks, completing these tasks and collecting feedback very early. 



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events