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.
We’ll use the chart above as a basis for the explanation. Above the
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.