The Blog of Brandon Milford - Marketing, Entrepreneurship, and Design

We’ve been re-designing our user interface since January and
we’ve tried some new things with this project, notably our development process.
In the past we had meetings, decided what we wanted to build and how it should
work and an in-depth requirements document was written. While it sounded good
in theory and looked quite nice on paper, it was never that easy and efficient
getting from point A to point B. The who, what, where, and when was
challenging. It was challenging as there was no understanding of who could
provide feedback when, who made the decision of what was implemented, and it
was tough to know where the developers were in the development process. I am in marketing and looked at the process
from the outside. It was very tough to see how far along development had gotten
on a feature that I was following. So with the design of the new interface our
development team decided to implement a different development process called Scrum.

I had never heard of it, but I’m loving it. Scrum changed
things quite a bit, but all for the better. Using Scrum our development process
now works like this:

• Anyone in the organization can submit feature requests via user stories.

• These user stories are then placed into a product backlog that is prioritized by a product manager.

• A meeting is then held where items (user stories) on the list are brought up for discussion, clarification, and finalization of rank based on what the team feels is of the greatest and least priority. Anyone within the organization can attend these meetings and contribute.

• Once this meeting is adjourned (typically a 4-5 hour meeting) the development team is prepared to begin work on these items.

• The development team works in 30 day sprints. So all items on the list must be completed in the 30 day sprint.

• Each morning the development team has their daily scrum meeting where they discuss what was accomplished the day before and what they plan to complete for that day. Anyone outside of development can attend these daily meetings to stay up to date on what is currently under development, however no outside input can be given as all topics, decisions, and priorities were agreed upon in the meeting prior to the sprint, known as the Sprint Planning Meeting.

• The day in which the sprint ends is a set day and does not change. What changes as the last day of the sprint approaches is how certain items are implemented. For instance, if it will take an extra three days add a feature that is more “cool” than necessary the “cool” feature must wait until the next sprint if the sprint deadline is not met.
      
• At the conclusion of the sprint there is a Sprint Review Meeting in which each developer presents their work completed during the last sprint. This meeting, like the Sprint Planning Meeting, is open to anyone within the organization.
      

Here’s a diagram of the process:

As far as quality assurance, we have integrated into the
system and the QA Engineer works closely with the development team throughout
the process.

It has been an interesting transition for the entire company
as it has allowed everyone to be involved in the development process while
maintaining order and keeping a clear goal in mind.

Do you currently use Scrum?
If so, share your experience with us.

If you’d like to learn more about Scrum, check out the
following links:

• Control Chaos
• Mountain Goat Software
• Wikipedia