Project Planning: The Software Development Way

In class this past Tuesday, facets of Computer Science project planning was brought up. I feel that I have a unique perspective of project workflow coming into Digital Design Workshop due to my experience in Computer Science. Digital teams, I’m sure, have many unique ways to plan and complete a project. Likewise, software development teams have their own approaches.

One of the most popular workflows is called Scrum, and it is built on principles found in the Agile Manifesto. To summarize these two, Agile is a methodological movement, and its objective is to frame the way we view our projects and its goals. Scrum is an implementation of Agile, a specific process to implement Agile teachings into a real project workflow. Knowing a fair share about these two topics shapes my mind to think about our website-redesign project with RCS in a specific way. Perhaps my peers can glean a different perspective in digital project planning and workflow by comparing their own process to Scrum, so I will try to provide an overview.

Scrum workflow chart.
Scrum is a workflow for completing a software project.
A workflow is a series of defined processes that describe how a team will work in order to complete a project.

We’ll use the chart above as a basis for the explanation. Above the arrow path are various silhouettes of people or groups of people. These describe roles within the development team. The nodes along the arrow path represent stages of development.

The Product Owner is someone who is trusted to represent the client’s needs for the project. As I understand it, this person could be an in-house liaison or someone from the client’s company. They add items to the Product Backlog. The Backlog is a list of granular product features that have yet to be implemented, AKA a To-Do list. Items on the Backlog have a time estimate (how long will they take to code up?), a priority, and a description. The Team pulls items off the backlog when they finish the features they’re currently implementing.

The Team is in reference to the development team – those completing the project. They all plan Sprints together. In Scrum workflow, a Sprint is basically a timed development cycle. During a Sprint, the team is actually coding features that they’ve pulled off the product backlog. The duration of a Sprint depends on the team and project, but it can range from 1 to 4 weeks. They determine which features to implement based on the feature’s dependencies, priority, and time estimation (they add up the days of features to try and fill up the Sprint with tasks to do). Each team member is then assigned some features based on skillset. At the end of a Sprint, the team demonstrates the working software features they’ve added to the client. If the client approves, then the feature can be marked as finished. They also hold a Retrospective meeting in which they discuss areas of improvement for the next Sprint.

The Scrum Master is a developer who oversees Sprints. They are a servant leader who tries to remove obstacles that team members experience during development. Part of this is facilitated by holding daily standup-meetings with the team in which each member states what they’re working on for the day and any obstacles they have.

The Sprints and client inclusion are aimed to help the product be as close to what the client wants as possible upon project completion. In the past when development teams tried to plan out every project detail, and then implement the whole project, the teams discovered the client often changed their mind about features when they saw them, that the client didn’t articulate the feature well, or that the team misinterpreted the feature description. The idea is that Agile and Scrum circumvent this problem by keeping project development in an ever-evolving and ongoing client-involved process.

Leave a comment

Your email address will not be published. Required fields are marked *

%d bloggers like this: