Best Breed of Software Development Practices

In our previous blog post, we talked about how we composed our own methodology putting Scrum, XP and Kanban together in a mix. In general a methodology explains only the general guidelines. Yet those guidelines need to be followed by practices on a daily basis. This blog post will be about those practices. We set those practices for sprints with two-week cycles.

1. High Level Sprint Planning – Sprint Goals

Right after the evaluation of each sprint evaluation and wrap-up (more on this below), we make a high level plan for the upcoming sprint. We decide on a set of new features, improvements, goals. This set should be aligned with our product strategy.

On Monday morning of first week, detailed sprint planning starts with cutting the high level goals into smaller work items. Then we

prioritize,

estimate (more on this at the end of the post),

assign and

plan

them for the 2 week period. We write everything down on a whiteboard. This makes the goals, work items, and detailed plan visually available to everyone at all times.

These work items are either created on spot or picked from the product backlog. Our work items are not hierarchical but rather a flat list. We don’t get lost in the deep darkness of categorizing the work items as ‘epics’, ‘user stories’, ‘tasks’ or ‘to-do’s. A work item is a work item and it needs to be done, simple as that. If they turn out to be bigger than the initial estimation then we break them into separate work items.

Detailed planning can take as much as half of the day. If it needs more time, we continue on for a little bit more. Planning is always worth it, no matter how much time it takes. Now and then we run into a goal where our understanding is not clear, and debate on how to break it down goes on during planning. We then stop the discussion, identify the work items that will clarify the issue and enable us to move forward, leave the rest of the goal to a further sprint or time box the effort for the rest within current sprint.

2.1. Work item estimations

This is a topic that deserves much longer explanation so it deserves another blog post. Here we keep it short to ‘what’ and ‘how’, excluding the ‘why’.

We evaluate the work items in terms of time units – even though this is widely advised against, but use ‘complexity’ or ‘business value’ metrics instead. So far we have seen that this is the most efficient way. “How much the business value is” does not mean much while you are trying to assign people to tasks and try to reserve some time in your calendar. It is in the plan, so it is obviously ‘worth’ it.

Our unit of estimation is ‘person-day’. This means a 1 person-day of work would take 1 developer a full day to finish it. It can also mean, 2 developers can finish it in half a day if they do pair programming and work together (explanation of how this is possible will be in a future blog post).

We divide the calendar in half-day blocks (as morning and afternoon) and assign tasks to developers for the full 2 weeks. Below is an example;

3. Daily Stand-ups

We stick to the common practice of daily stand-ups. In a limited time of 15 minutes, each developer answers three questions:

What did she/he do the previous day?

What will she/he do today?

Are there any obstacles preventing him/her to go further?

The daily stand-up is done in front of the detailed plan on the whiteboard, therefore plan is visible to the whole team during the stand-up. Keeping the two-week plan in mind we focus on two main things. First we check if everything is still on track for the developer. Second focus is for relatively smaller questions about the tasks. Stand-up sessions are about progress and problem resolution from both developer and the team members. If an issue is raised and needs more detailed discussion or study, we focus on that after the stand up.

Things might not have gone as planned the day before and smaller adjustments on the plan might be needed. Stand-up is the time to do adjustments like re-placing tasks, re-assigning, postponing or canceling, in case there are rational reasons.

4. Mid-Week Evaluations

We do this meeting on Wednesdays right after lunch; exactly the mid of the week. Limited to 30 minutes, we check the status of the goals. We mark accomplished tasks and check if the remaining goals are still reachable within the upcoming half of the week.

In case our initial plan does not seem attainable anymore, this is the opportunity to discuss and revise the plan in detail. Revising can consist of canceling goals, postponing them, rescheduling or reassigning.

We also check if there are too many tasks in the testing phase or in progress phase. Those are the early warning signs that would show if something is wrong.

5. Mid-Sprint Evaluations

End of Friday of the first week is the spot for this meeting. Limited to 30 minutes, we look at the scope of the sprint again and ask;

Are the sprint goals still attainable?

Did we accomplish first week goals?

Do we need to postpone any of the goals to the second week?

Do second week goals need a revisit?

Does second week have a detailed plan?

Sometimes we leave the detailed planning of second week to this meeting. Then this meeting can take a little longer than 30 minutes.

6. Sprint Evaluations

We reserve the last hour of the second week’s Friday for the sprint evaluation. This meeting is only about

What we did good and

What we did bad.

We consider not the content but the process and methodology.

We set action points like what to keep doing or what not to do anymore.

During this session we also do a brainstorming session on what we can improve and if we can bring in new practices. For example, mid-sprint and mid-week evaluations, intensive pair-programming and high level planning were outcomes of those sprint evaluations.

7. Sprint Wrap-Up

Once the sprint evaluation is over, we need to do few more things to wrap up the sprint. We check the status of the goals we set at the beginning. Sometimes there are a few that we cannot accomplish. We make a decision about those; either move it to the next sprint of park them in the backlog for now. After that we cleanup our board; we go through the work items that are in the ‘Testing’, ‘In Progress’ and ‘Current Sprint Backlog’ phases. We mark those that are done. Just like how we do with the goals, we decide on what to do the work items that are not done; move it to the next sprint or park them back to the backlog. After all of those cleanups, we are now ready for the “High Level Planning” for the next sprint, so we start on that.

Conclusion

Those are the tools of the trade we use. Is our methodology mature and are those all of the practices we use? No. Conditions will change and we will keep learning. As we analyze our experiences, we will keep evolving. For now, we envision, plan, stay loyal to plan and be flexible at the same time, dedicate, keep talking and evaluating as often as possible, and stay focused.