Overview of Agile Scrum
For project management and software development there are numerous approaches that help your support teams get the job done. However, if these methods are not familiar, well understood, or properly used; their misapplication and the related miscommunications can lead to exercises in futility. When engaging with our clients and prospects we outline our approach to project management to let them know what to expect. We primarily draw from a common methodology for software development, called Agile, and use a process framework called Agile Scrum. Today, we would like to share with you how we pair this methodology with project management tools to deliver solutions to our clients. Below, we will introduce some of the more common software development methodologies, how they work, and how you might interact with them. After reading this post you should, at a minimum, be able to better understand what your developer team is doing, why they are doing it, and relate to some of the unfamiliar words they use.
Agile project management stems from a document titled the Agile Manifesto. Agile can be applied to a multitude of different disciplines beyond software development, however, within software development you can find it in the form of different Agile frameworks such as Scrum, Extreme Programming (XP), Crystal, and Feature-Driven Development (FDD).
Scrum favors speed over documentation, it favors small incremental deliveries, which can be checked for function and validated with clients, reducing the risk of going down the wrong path too far or even possibly missing a new idea, over fully functional software heavy products.
Pillars of Agile Scrum
There are 3 pillars to Scrum: Transparency, Inspection, Adaptation.
- Transparency stands for creating shared standards, language, and terms as well as making sure that all stakeholders involved in the process have a clear understand of both expected outcomes and current status.
- Inspection represents the idea that there must be consistent and frequent, yet not overly overbearing, inspection of the elements of Scrum.
- Adaptation stands for the proper correction of processes and work after proper inspection has been done and it’s been deemed that the resulting outcomes won’t meet the objectives of the project.
Quickly Getting Started with Agile Scrum
At Anant, we use Scrum for project delivery related to our own research & development efforts as well as for client projects. There are other tools available but we leverage the following three pieces of software to manage the Product Backlog, the Sprint Backlog, and the Increment elements of Scrum:
During our initial project kickoff meeting, we sit down with clients to decide the main capabilities they want to deliver during the span of the project, and in turn what features the software should have. We then prioritize these features into a number of sequential releases. Each release will have an overarching outcome and will be broken down into individual user stories in the form of Trello cards. Trello cards give you a visual depiction of the remaining user stories that need to be completed before a Release can be considered done.
We then decide how many increments of time will compose each release. In Scrum these increments are called “Sprints” and a release is usually made up of one to four sprints. The maximum size of a sprint itself can be no longer than 4 weeks, as dictated by the Scrum Guide, but also should not be any shorter than 1 week. Keeping Sprint length between one to four weeks makes work more manageable, and gives clients the opportunity to validate features and functions as they’re developed, and even possibly make tweaks along the way. Sprints and Releases are all time-boxed events which have set start and end dates. These dates are fixed once the Release and Sprint begin, but can be reviewed and adjusted by the Scrum Team if needed, as they learn more about the project.
At the end of each Sprint the Scrum team will get together with the client stakeholder(s) and review progress made during the sprint during the Sprint Review. Once that is complete, the Scrum Team will meet as a group to conduct the Sprint Retrospective, during which they will evaluate their previous Sprint performance as it relates to people, relationships, process, and tools in order to improve their effectiveness during the next sprint.
Tracking Progress for Agile Scrum
Below you can find the standard Trello board template that we use when delivering a project using Agile Scrum. On this board, both the Scrum for Trello and Burndown for Trello plugins are enabled. If you look at the top right section of the image below you can see the total estimate of hours (13) for all tasks on this board and the total amount of consumed hours (3.5) thus far.
Trello cards, representing tasks, are ordered via highest priority on the list. A card at the top of the list is of more important than one at the bottom, additionally cards that are higher on the list will also contain greater detail of the work required. Usually the product owner, and in the case of a client project, the project manager, will sort cards by highest priority with input from the different stakeholders, this process is called “Backlog Pruning”. Anyone on the Scrum team can create a card in any of the lists available, however cards cannot be added to a sprint mid-sprint.
The Burndown for Trello plugin works in conjunction with the Scrum for Trello plugin. In the above burndown chart, the Scrum Team will aim to stay as close to the burndown rate reflected by the orange “Ideal Burndown” line as much as possible. This burndown rate goal is sought due in order to maximize the amount of opportunities the Scrum Team will have for inspection and adaptation – if all the work was rushed within the first week of sprint for example, there would be far less valuable time for the Scrum Team to collaborate effectively and receive client feedback.
At the beginning of the sprint the blue “Hours Remaining” line should be at its highest value, there are times, usually at the beginning of projects, where the Scrum Team will need to re-adjust estimates in order to reflect new found knowledge relating to the project, but as a whole the Scrum Team will strive to avoid that situation and as the project progress estimates become better refined in subsequent sprints.
Elements of Agile Scrum
One of the main goals of Scrum is to foster transparent and effortless collaboration by the entirety of the Scrum team. On daily basis we will conduct a “Daily Scrum” check-in with all the members of the Scrum Team. During that short check-in that only lasts a maximum of 15 minutes, each team member will state what they worked on yesterday, what they’re working on today, and if they have any blockers to that day’s tasks. After the call, if any blockers were mentioned, the team members who are affected by the blocker(s) will stay on the call after everyone has left and take steps to resolve the blocker(s), this period of time is called a “Parking Lot”. The goal of the Daily Scrum is to have a good understanding of the progress of the project, remove impediments, take quick and sound decisions, and improve overall communication and collaboration within the Scrum Team.
- Bugs
- Bugs are flaws, inconsistencies, or failures that occur in a software system such as online application or content-focused website. Essentially, a bug is filed if some functionality is not working properly. These type of tasks can usually be resolved in between 1-5 hours.
- Product Backlog – NoBurn
- A Product Backlog is a list of tasks that the Scrum Team isn’t currently focusing on but which will need to be addressed during a future Sprint.
- Items in the product backlog shouldn’t be included in the total working estimate until those items have been placed into the Sprint list.
- “NoBurn” is a term that we use in our list titles so that the Burndown for Trello plugin does not account for the hours estimated for the cards in this list (see instructions on how to use the Burndown for Trello plugin here).
- Sprint 1 (dd/mm/yyyy – dd/mm/yyyy)
- The Sprint list is dedicated for items that the Scrum team has decided to work on during this sprint. The items are organized in order of priority.
- In Progress
- The In Progress list contains items that are currently being worked on by the Scrum team.
- Stage – Done
- The list Stage – Done contains cards that have been completed by the Scrum but that have not yet been “accepted” by the client or stakeholder. Once cards are moved into the Stage – Done list our team will have a meeting with the client and the client to ensure that they consider each of the cards completed. Most often the client can determine that by going to a staging URL if the work involves programming and seeing the feature in action. In other cases the client will need to review a business requirements document. There are a variety of ways for the client to determine whether the work is complete or not, which, of course, depends on the user story that was delivered.
- The term “Done” is another term that is needed when using the Burndown for Trello Plugin. Cards that are found in a list that contains the word “Done” in them will be considered complete and the remaining estimated hours for that card will not appear in the Burndown Chart.
- Sprint 1 (Release 1.1) – Done
- This particular list will contain user stories that have been accepted by the client. They are not necessarily triaged in order unless the product owner or client on the project has something in mind.
Every Release incrementally delivers a potentially shippable piece of software – which means that if the client wanted to go “live” with this application they could do so. It might have limited functionality, but the particular set of features delivered in that Release would be functional for users. Agile Scrum enables us to keep our clients in the loop with both consistent project updates, as well as the ability to showcase working functionality at the end of each Release.
Conclusion
At Anant we have used Agile Scrum to deliver projects related to data warehousing, SaaS systems integration, analytics, online form applications, integrated search applications which index data from multiple API and web-crawl sources of data, as well as a multitude of other engagements. Our team members have actively been part of Agile Scrum teams managed by partner companies with which we teamed up to deliver projects such as the re-design and implementation of a massive search application for the US Patent and Trade Office (USPTO), and design and delivery of an angular search application for the University of Michigan Health System (UMHS), to name a couple.
If you have any feedback (always welcome, bad or good) or questions related to this article, or perhaps are interested in a lunch & learn on this or another topic, please don’t hesitate to reach out to me at arturs@anant.us!
Want a long-term technology partner that can help you navigate your organization’s technology needs? Sign up for a free Roadmap conversation to speak with a business-savvy technology expert here.
Additional Resources
PS: If you want to learn more about this subject as well as read about a bad experience with Agile Scrum see the resources below:
- The Scrum Guide by Ken Schwaber and Jeff Sutherland, the creators of Scrum
- The Scrum Master Training Manual by Management Plaza, a very thorough review of Scrum that gets into very practical detail
- Quality Assurance (QA) and it’s role in the Agile Process
- Professional Scrum Master (PSM) versus Certified ScrumMaster (CSM)
- Counter Point – Why I’m not a big fan of Scrum
