SCRUM Sprint Planning Gone Wrong

One of the things that is a hallmark of the SCRUM method of Agile development is that you have a unit of time during which you commit to accomplishing some amount of work before that unit of time has elapsed. In order to commit to how much work should be accomplished during the “sprint”, all members of the team meet at the beginning of each sprint for a sprint planning meeting.

The purpose of a sprint planning meeting is to estimate the difficulty and complexity of completing each task that is in your list of potential work items. At the end of sprint planning, a subset of these items will be picked as the set of items that the team commits to completing by the end of the sprint. While this all sounds straightforward and simple to most people, I have been in some sprint planning meetings that lose their focus.

Since there are typically quite a few items to estimate during a sprint planning meeting, time spent discussing implementation and testing details should be kept to a minimum. The SCRUM Master is responsible for ensuring the meeting moves at a reasonable timeframe so that the sprint planning meeting does not exceed the scheduled timeframe, typically 1 hour.

There have been several sprint planning meetings I have attended that had members of the team determining how the issue would be resolved during the meeting, instead of just estimating the difficulty and complexity of the task. It would not be unusual to still be discussing the merits of the first task more than 30 minutes into the meeting. Unsurprisingly, the projects this team was supposed to deliver were always behind schedule if they were ever considered feature-complete.

Related Posts

Mar 30, 2015
2 minutes

Optimize Wide To Narrow

If you consider the path that a user takes through your website from landing page to successful conversion, you can think of the number of users that make it to each point along the way to a successful conversion as similarly shaped to that of a funnel. In a typical setup, you may have a very small percentage of your users make it to a successful conversion, but there are several areas along the way that either improve the chances the user will convert or decrease those chances.

Mar 11, 2015
One minute

Firefox 36 Has A Massive Memory Leak

While looking through our TrackJS logs the other day, I ran across a peculiar error message coming from Firefox 36 on Windows 7. The error message was simply out of memory. It seemed that the pesky local storage issue had reappeared mysteriously. However, with a quick check of the codebase, I verified that no one had accidentally reverted those fixes.

With that possible cause ruled out, I turned to a developer’s best friend, Google, for solutions. Well, it appears that Firefox 36.0.0 has quite the memory leak issue. When looking into the detail of the issue, it became highly probably that this issue was the cause of the errors in our monitoring tools. Apparently, this bug rears its ugly head when you are doing 2D rendering on your page, and the site uses a 2D charting library to present information.

Mar 12, 2015
3 minutes

The Number 1 Cause of the Not Invented Here Syndrome

One of the quickest ways to get a new internal tool bootstrapped is to utilize an existing design, making slight adjustments to ensure the design matches the requirements of the current project. Instead of using another internal tool as the basis for the new design, I used a design that was purchased specifically for this project.

This particular design was unique in that there were multiple working examples using AJAX, pure HTML, and AngularJS. While it was nice having supposed working examples, when you start to look at the readme file for how to get this functionality working on your own hosting setup, thats when the niceties disappear. Specifically when lookng at the readme file for AngularJS, it effectively says: “Because this is a well-known JavaScript framework, we are not including any documentation for how it works or how to get started with our design”. Granted, the inner workings of AngularJS need not be covered in the readme, but a simple walkthrough of what to expect this design to do would make things much more user/developer friendly.