How to run your daily Standups Effectivly

Standup meetings are short. The reason why they are called standup meetings is that they shouldn’t last so long that people feel the need to sit down. You simply go around the room and asking “What did you do yesterday, what are you going to do today? Do you need any help?” This gives you a high level of understanding of the current initiatives underway. However, alone this does little to tell you if you’re going to meet your deadline.

As I mentioned before, there are many software development lifecycles that help you track progress. Agile methodologies are the most popular. At the root of these methodologies is basically identifying a chunk of work that needs to be done, and estimation of how long the work will take. Then tracking the actual time it took.

For example. Let's say you need to develop a search page for your products. A specification document is usually written up identifying what the problem is that we are trying to solve and the proposed solution to resolve it. In this case, users need to be able to search for products easily. The proposed solution is a web page that allows the users to search for products in inventory based on name and description as well as price points.

So let's say the developers received this specification document and broke it up into tasks. From database infrastructures to the design of the page. After this, the estimated total hours between let's say 3 developers were 240 hours. If every developer is expected to work 8 hours a day, those 8 hours are not fingers on keyboard hours. Between meetings, emails, research and breaks let assume you get 70% of their time actually coding away. which means each developer should realistically report roughly 5.6 hours a day (8 x 70%). With 3 developers working on this that gives you 16.8 hours total “burn down“ each bunnies day. Therefore, 240 hours of work will take approximately 14-15 days which translates to 3 business weeks. obviously you would need to account for the level of error in their estimations plus QA cycles and Deployment. However, let's just stick to the development time for now.

So every day at your stand-up meeting; You go around the room asking everyone how many hours they burned down and which tasks. At the end of the day, you should have a graph of their burn down that lets you know what’s expected. So if you’re 1 week in, you should have a third of the project completed; if you are at less, then you’re behind and can address that at an early stage.

Do this every day. Don’t make a big deal out of it, just do it. At the end of the week, my project manager sends out a report that basically says: “Hey everyone! It’s Friday, and we are X% complete. If you’re really behind, you need to catch up by Monday please.” And most good developers never work on weekends, because they make sure they don't fall behind. This also has another advantage for a developer that hates being micromanaged. If they are hitting their numbers then they can come and go as they please. If they need to leave early one day as long as they catch up by Monday then they can recover. And they should have the freedom to do so.

At the end of the sprint, the actual time spent vs estimated time will be either over or under. Hopefully, they will average out. But both the developers who overestimated and the developers who underestimated will know now how to adjust.

11 views0 comments