Agile Project Breakdown

Project management
Goal:
When I was asked to be project lead of a initiative to create a new home page for StudyBlue, I was determined the project should be delivered in a timely manner. Several previous projects at our company had run too long due to allowed scope creep. These prolonged projects were frustrating for the whole team, especially the engineers, so for the new homepage project, I wanted to prevent scope creep as much as possible by bringing up details ahead of time and breaking down the project into manageable releases.

After the designer and product manager presented us with the Sketch designs of the new home page, I took the time to look over the designs and asked as many questions as I could think of to preempt issues that would come up later in the project. The product manager's answers helped me understand the full scope of details that would be included in the project. With this clear idea of the project scope, I brainstormed the best way to break up the project into manageable chunks. I took into consideration both the user experience as well as the engineering effort necessary for the tasks. I eventually came up with the following breakdown.

In addition to this visual guide to the releases, I also created some notes on the breakdown to clarify some details for the QA and engineering team.

I also made a point to attempt to give the components of the page names we could all use. I did this because I often noticed that the Product and Design team would often use different names for components than the engineers did when building the components. This naming difference often made conversations on the projects more confusing.

Finally, I made a point to create HTML classes and CSS styling that were global and could be reused on other pages. I also added these styles to the styleguide to promote their reusability.

Reflection:

Overall, I was pleased with the impact this planning had on the project. From an engineering perspective, it made the project feel far more manageable and contained. And it seemed to make the engineering, product, and QA feel like we were all on the same page. Of course as the project evolved the releases needed to be adjusted but that was no problem. Unfortunately though, my attempt to create set names for components didn't seem to address the problem. Although it's a step in the right direction, I think other tactics are needed.

While I feel like I have a knack for this kind of organizational work, I often feel this kind of work distracts me from being able to focus on advancing my technical skills. After this project I asked my supervisors to allow others to organize projects so I could focus more on my technical skills.