One tip you should know to establish your sprint cadence


Vivek: “Hey Rajan, are you all set for the demo on leasing functionality?”
Rajan: “Yes Vivek we are but there is a glitch. Tom and Brady have taken off tomorrow to have a 4 days long weekend clubbing it with their Labor day holiday on Monday. So the earliest we can have it is on next Tuesday. Is that ok?”
Vivek: “umm. OK. Not ideal but can’t help much here. Let’s push both the sprint review and the retrospective to next week.”

Have you encountered this situation in your scrum teams? How do you react to this? Did Sanjeev assume too much or felt that Rohit was not being too honest? Did Rohit feel that he had left Sanjeev down?

How many times has this happened with your scrum teams? 1, 2, 3 or umpteen times? If the answer is later, it is worth considering your sprint cadence.

I assume that you are having a 2 weeks’ sprint in your teams. 4 weeks is too long a window to deliver valuable product for your customer and close the inspect/adapt loop though I would prefer 1-week sprint if you have well established DevOps tool chain in your organization.

During my consulting assignments, I have typically seen scrum teams aligning their cadence with start-end of week.

Typical Cadence:

  • - Sprint starts on a Monday
  • - Sprint ends on a Friday (10 business days later)

Pitfalls of this approach:

  • 1. Mondays and Fridays are typically the days that people take PTO/day-off to combine it with the weekend. Because the sprint review and retrospective is a time to reflect on the product and the process, we need the full Scrum team to attend.
  • 2. Stakeholder/Customer meetings on Fridays can be an erratic with distributed geographies / time zone differences especially late on a Friday evening
  • 3. Friday being the last day of the week means that people are usually tired and not able to concentrate to finish the sprint (they just want to go home for the weekend). Is this the right time for teams to be deploying work into production?
  • 4. Starting on a Monday could tempt PO/SMs to ask teams to stretch and work over the weekend to be prepared for demo on Monday. Let’s maintain a sustainable pace.
  • 5. If teams have the ability to deploy anytime, mid-week is ideal rather than Friday when everyone is leaving for the weekend. Deploy mid-week while the team is more available to support.

Proposed Cadence:

  • - Sprint starts on a Wednesday
  • - Sprint ends on a Tuesday (10 business days later)

If you have been following the Monday through Friday cycle, experiment-inspect-adapt your cadence with below calendar. Hopefully, you should have all tick in the boxes with your cadence, eventually helping you deliver awesome products for your customers!

Keep Learning and Improving!

How much DONE is your definition of done (DoD)?


Scenario I

Rohit, the developer, finished his daily scrum and walked to his seat and was approached by his functional manager Sanjeev who asked if his story on seller payments was done. He had completed his design, checked in his code, completed unit testing and promptly said, "Yes!". "In that case, let me ask release team to deploy it in the business testing environment", said Sanjeev. Rohit then put in a word of caution, "But Sanjeev, we haven't still finished testing with Selenium scripts, Vivek is still on it".

Have you encountered this situation in your scrum teams? How do you react to this? Did Sanjeev assume too much or felt that Rohit was not being too honest? Did Rohit feel that he had left Sanjeev down?

Go no further, there is a tool in Scrum which can deal with situations like these called Definition of Done (DoD).

DoD is primarily a simple list of valuable activities (writing code, unit testing, documentation, reviews, automation) required to produce working software. This also serves as the primary reporting mechanism for team members to sync their updates during daily scrum. DoD is orthogonal to the acceptance criteria of a user story and typically applicable to all the user stories unless explicitly stated.

Below is a guiding checklist which you can use to formulate your DoD : -

  • 1. Code produced (all ‘to do’ tasks in code completed)
  • 2. Code commented & checked in source control
  • 3. Peer reviewed (or produced with pair programming) and meeting development coding standards
  • 4. Builds without errors
  • 5. Unit tests written and passed, code coverage > 90%
  • 6. Automation testing complete
  • 7. Deployed to system test environment and passed system tests
  • 8. Passed UAT (User Acceptance Testing) and signed off as meeting requirements
  • 9. Passed security & performance testing
  • 10. No outstanding P1/P2 defects
  • 11. Any configuration changes checked in along with a well-defined rollout/rollback plan
  • 12. Relevant documentation/diagrams produced and/or updated
  • 14. sRemaining hours for task set to zero and task closed in tracking tool

Scenario II

"But wait a minute, isn’t this a long list of activities to complete in a 1 or 2 weeks sprint length. We have dependency on security and performance testing which are outside of our scrum team. We also have to work with ITSM team to raise ticket for production change & get sign-off of release & deployment plan as part of CAB meeting. IT operations provide resources to work on firewall and db changes. All this takes typically few weeks' time to finally deploy working software in production environment ", If we have this DoD, we won't be able to complete any story in a given sprint", retorted Kapil..

Kapil misgivings are correct to some extent. Consider a large organization which has multiple scrum teams & have structural system impediments with few centralized teams doing certain specific functions, how would you deal in such situations? For smaller teams and startup organizations, it may work but not for bigger corporations. How would you ensure your teams are able to ensure 'done'-ness of their work?

Scrum asks the teams to delivery potentially shippable software at the end of every sprint. To me, potentially shippable software can be released via continuous deployment tool chain at product owner’s discretion in live environment with a limited notice say of 1-2 days. Ideally potentially shippable software is equivalent to definition of done.

Given the above realistic scenario, there may be multiple hops to the reach the potentially shippable state within an organization. Such teams may look at having DoD at different levels.

  • 1. Definition of Done for a story
  • 2. Definition of Done for a sprint (collection of stories)
  • 3. Definition of Done for a release (potentially shippable state)

There are various factors which influence whether a given activity belongs in the DoD for a feature, sprint or a release. Finally, the decision rest with the team via answering to the following three questions:

  • 1. Can we do this activity for each story? If not, then
  • 2. Can we do this activity for each sprint? If not, then
  • 3. We have to this activity for release !

The foremost thing that you need to take care is to brain storm with your team on all the list of activities which help you convert a story into a potentially shippable state. Once you have all the activities, then you apply these questions and then formulate DoD for each state.

Let’s take an example:

  • 1. DEV-QE may swarm and test a story with a mocking interface or test a story in isolation in the dev sandbox to meet DoD for the story
  • 2. To meet DoD of a sprint, QE may test with an actual back end interface or test with all dependencies in a controlled test environment
  • 3. To meet DoD of a release, scrum team may bundle all the stories across multiple sprints and get them performance and security tested with the central team as a release component.

DoD is not static & may change over a period of time. Organizational support and team’s ability to remove systemic impediments via devops tool chain or structural changes may enable teams to have a unified view of the DoD which is an ideal state.

If you do not have a formal definition of done (DoD), try it out. I do hope that building a DoD in this manner will help your team get a leg-up in your agility journey.

Keep Improving !

I am neither a fitness trainer nor a tourism ambassador but through this blog want to draw your attention to 'Agile Testing' - one of the most important yet often flawed implementation resulting in one of the biggest impediment to your agile success.

Before we start, who is an Agile Tester? There should not be marked distinction between business, development, operations, testing and architecture skills in an agile team. What matters the most to least in the order are your skills, roles and then title in that order. Increasingly, what I am seeing is now a trend to have full stack developers which have specialist-generalists (T-skills) with a combination of either of Dev-Test, Test-Dev, Dev-Ops, BA-Test skills and hence, this blog is relevant to the entire agile team and not specifically only for testers.

OK, coming back to the subject, here is what I have often seen on CSP model at multiple client locations implementing either Scrum-Fall or Scrum-But agile implementations:-


  • 1. Separate SIT Team, UAT Team, Perf Testing and Security Testing team
  • 2. Siloed team structure with each having separate line of reporting)
  • 3. Development scrum team spends time on hand-off with these multiple testing teams


  • 1. 4 weeks of iteration
  • 2. Fatty stories which spill and span across multiple iterations
  • 3. Developers hate to write unit tests. Although they are factored in the tasks, nevertheless when push comes to shove due to time constraints functional implementation takes precedence and unit tests are kept in the back burner
  • 4. Test driven development (TDD) is absent
  • 5. Few Selenium automated UI tests to showcase automation exists
  • 6. Time is spent mostly on manual testing – test plan preparation, test case creation and test execution
  • 7. Huge effort of testing towards the end, once development is complete
  • 8. CI/CD pipeline is weak


  • 1. Push-Pull between the developers and testers waiting to prove each other wrong
  • 2. 'We' vs. They culture
  • 3. Blame game
  • 4. Developers only do development while testers only do testing

All the above symptoms of practice aspects of CSP model are represented by an anti-pattern called Ice-cream cone testing anti pattern.

As a CTO, you will spending millions of $'s on your agile transformation journey looking to onboard the best consulting company having experienced agile & devops coaches, purchase licenses for the best engineering and devops tooling, create agile workspaces with best in the class information & build radiators, take the teams through myriad agile trainings/workshops yet there is no focus on the organization blind spots which are the toughest icebergs to first identify and then solve. Let me also be put forward that without these in place, the gigantic ship of agile transformation will slowly but surely sink!

So what are these? CULTURE, CULTURE and CULTURE

Hang on for a minute, "You just mentioned 3 icebergs and this is only ONE. Additionally, what has culture got to do with agile transformation? Processes, Practices, Tools are much more important. I don't agree to this."

You have a valid point. Whenever I meet and tell this to our customers, this is the same rebuttal that I get. So let's first take a sneak peek into the Version One – 10th -Annual State of Agile Report to get an industry view.

What do you infer from the above report? If you look at most the above mentioned reasons for failure in agile projects, they only point in the direction of CULTURE where it is present at three different levels in an organization – Team, Management & Leadership.

  • 1. Team – General resistance to change, ineffective collaboration, unwillingness of the team to follow agile, inability to continuously prioritize work will prevent the team to move in the direction of 'Self Organization' and continue to rely on task master and command & control type of leadership.
  • 2. Management – Lack of management support, ineffective management collaboration will prevent the tenets of 'Servant Leadership' and 'Product Owner' collaboration when the management think that agile is applicable only for the development scrum team and does not need their involvement.
  • 3. Leadership – Company philosophy or culture at odds with core agile values, a broader organizational or communications problem will prevent ‘Leadership Agility’ where leadership has a hands-off approach to solving organization dysfunctions and systemic impediments which prevents the organization to steer towards Agile Culture and Business Agility as a whole.

The last line in the context is very important – ‘culture manages you and you many not even be aware of the extent to which is happening’ which relates to the first point which I mentioned in the opening of the article - where this is a blind spot and an iceberg – you cannot spot it and very difficult to change. Therefore, this needs be the 1st and most important point on an agile transformation journey which an organization should address.

More on culture transformation solution / options in the upcoming series.

Keep Improving and Stay Agile!