Thrift Shift
Agile Methodologies // Project Management // User Flows // Wireframes
As digital products become more tightly entwined in our lives, managing these products and breaking their components apart into programs and projects will become commonplace. However, to manage these projects, the old style of tracking projects commonly knows as waterfall or phase-gate simply cannot keep up with the speed of digital development.
That is why my team in the mpd2 program at Northwestern University practiced Agile software development for the design and production of Thrift Shift.
Setting the stage.
We started the class by choosing to work on Thrift Shift within the first 30 minutes of class. By presenting to our entire class and receiving feedback, we were replicating how it was to work with stakeholders and people who were invested in the success of our app.
It was soon after this that our professor introduced us to our developers. For the next 4 weeks, we would be tasked to work with 5 undergraduate developers to build a web-based app. Their objective was to also learn how to work in agile.
Finally, the new team got together and started hashing out exactly what we were going to do. A product owner was chosen, initial designs were shared, and a weekly scrum date was chosen.
We understood that due to our limitations of meeting in person and being full time students that running a traditional daily stand-up meeting would not be possible. However, we were in constant communication with our developer team to make sure things ran smoothly.
Agile Tools.
Wireframes.
Wireframes are low-mid fidelity layouts that determine a website's front-end structure. Using wireframes allowed our developer team to quickly start working on the highest priority user stories.
Scrum.
Scrum is the daily meeting that development teams have with their project managers to bring to light problems, help remove roadblocks, and refocus development. Due to our limitations, we held scrum twice a week.
Burndown Chart.
As a visual representation of the project’s progress and velocity, the burndown chart we used greatly helped us understand how to adjust the amount of work our development team could handle.
Testing.
By reaching out to our target users, once user stories were complete, testing became our greatest ally in identifying gaps in the story, features to be added in, things that didn’t work, and how to address them.
Links.
In 5 weeks you CAN build a full-scale app that is ready for launch, but unfortunately, that is not what our team did as our app was too complicated due to the relationship between the two user bases.
Here you can find our Adobe XD wireframes and the GitHub pages for our project.