Skip to content

Wayne State University

Aim Higher

Aug 28 / Robert Vrabel

Going Agile

Over the past week our team has been planning for a big change in how we are going to develop the next version of wayne.edu. We are piloting a process to start working in an agile development environment. There are so many ways to set this up. By no means are we experts on this topic, but I wanted to share with you our experience in getting started.

Building the sprint

A “sprint” is a short period of defined time that you have road mapped based on what tasks are going to be worked on and completed for each team or person depending on how much time is available. Rather than doing project management, development, design, QA and launch multiple times a day, we break these out into certain parts of the sprint to allow everyone to focus on the tasks at hand as a team. Here is a look at our first sprint:

waynedotedu - sprint 1

Monday – week 1

To start off the day we  figure out how many working hours someone has during this sprint. We plan for 6 days of tasks and 6 hours/day to work on those tasks. We automatically deduct some time for daily huddles, communication and working in our project management software. This leaves 36 hours/person/sprint . If someone is taking time off, you would subtract it from this number as well.

The next step is going through our backlog of tasks. We size, prioritize and assign them. We then start from the top of our backlog (in this case task #51) and see if that person has enough time to accomplish that task in this sprint. We also designate support time if someone needs help with that task. We do this until an individual is left with 0-3 hours of time. At this point in time you could get this build approved by business owners and easily show how adding other tasks would affect what has already been mapped out.

The next step is planning when this work will be accomplished. We tried mapping out the whole week, but we already have plans to do this on a daily basis or possibly on a 2-day schedule instead.

I possible, we also are dedicating time for innovation and blog posts.

Tuesday on week 1 – Tuesday on week 2 (6 days)

This time is designated to completing the tasks assigned and starting the sprint. Hopefully during this time no major tasks are injected into the sprint. If they are, decisions will need to be made on what will be bumped to the next sprint. The point is to focus on what we road mapped.

Wednesday – week 2

We are dedicating a whole day to do QA. During this time we will review every completed task and make sure they meet our standards. If not, we will take the time to improve the completed work as a team.

Thursday – week  2

On this day we plan to launch the latest work to our production server. We plan to announce this URL soon so you can follow our progress.  After it is launched we are dedicating time for any bug fixes that come out of this launch. If we have the time we will also work on small tasks that don’t impact much.

Friday – week 2

In the morning we are reserving time for more bug fixes that came out of the most recent launch. Next we will discuss how our latest sprint went. Did we size our tasks properly? Any hiccups? Can we improve anything for the next sprint? This is our chance to become more efficient for the next time we build our sprint and to make sure we are on track for success.

The rest of the day is dedicated to blog posts and  innovation time. During innovation time, it’s the team’s chance to discuss new techniques or new technology they have learned about. This way we are constantly improving our web development knowledge and keeping up to date with the latest trends.

The Next Sprints

We are just starting our first sprint and we are really excited to see how it goes. I’m sure you’ll see more posts in the future about our experience! I can’t finish this post without thanking my wife for taking the time to help me get an idea of how to create a sprint. She recently got a job in which she is a project manager in an agile development environment. Hearing her talk about her new job really inspired me to learn more about it. I absolutely believe it’s a much better way to work. Working closely as a team is much better than working as an individual.

Leave a comment