Agile, Improvement, Learning Lessons, Remote, Remote Leadership, SDLC, Technology, Tools

Daily Sprints – Day 0

Each morning for the next nine days, I will post about the previous day and hope to provide some interesting insights on how the team is trying to improve their estimation!

What have you tried that works or doesn’t work?!

Day 0

One team I lead added two new team members over the last two months and now we are storming . Specifically, we are having difficulty estimating how much work we can accomplish in a two week build cycle. There is a lot out there about improving estimation, removing estimation and everything in-between.

Since we added new team members, we tried different things to improve our estimation. At the start of 2018, we tried to commit to a little less work and meet an internal team code complete that was one day earlier than our technology team’s code complete to try and provide some cushion for issues that come up. We were unable to meet our internal code complete a number of builds in a row. We moved our internal team code two days in advance and committed a little less work. Still, we continued to run up against issues and we were not meeting our team code complete.

So now we are trying something totally different this build. We are going to try and make each day, one sprint. We will try to deliver working software at the end of each day, even if that is a hello world app.

Yesterday morning, we had our planning and commitment meeting, where we usually commit to eight development days worth of work. Instead of doing that, we committed to these agreed upon items for the next eight days.

  • Came up with lots of questions that we need architectural direction
  • Decided on how we are going to try a real TDD approach towards are next project
    • Start off “pair-programming”  to help everyone gain experience together
      • Using red-green-refactor method for TDD
    • After our stand up the engineers will get together and start pair programming
  • Committed to 3 stories to see how long it would take us to complete using TDD
  • At the end of the day, we will go over what we accomplished and any improvements (mini-retro)
    • Stand up the next day we will talk about what we are aiming to accomplish

Biggest concerns:

  • Time it would take to follow TDD, rather than coding first
  • Micro management concerns with daily sprints – is each day too little time to be productive?
  • Defining what is working software, especially in a culture where we often push work in bigger chunks, rather than small incremental changes
  • Designing solutions and answering question at the same time as we try to build out a software solution – can we start work before questions are answered? Or can we do it at same time? What is truly a road block?
(Header image credit:



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s