Jackrabbit Mobile Explains: Digital Project Operations & Development

Project Operations

Our project management processes allow our teams to produce great software at high efficiency. Creating beautiful, easy to use products and growing a dedicated group of fans is what gets us excited. Focusing on the ‘why’ and adapting on the fly enable us to do so.

We follow lean thinking and agile methodology. Having a strong vision is crucial from the beginning, but having a full spec document often isn’t.

A product evolves the fastest when you talk to customers, gather feedback, iterate, and actually start building. Therefore it’s best to focus on those processes instead of detailing out a master plan, which will likely change on day one.

The agile manifesto is the set of software commandments, but basically we prefer to do what works over rigid process. We prefer software that actually works over superfluous documentation. We prefer cross-functional team collaboration and iteratively adapting to change.

Our Process

Projects are divided into sprints. A sprint is typically a one or two-week period that focuses on an agreed amount of work, the highest priority items selected from the product backlog.

Focusing on these selected items keeps the team from being distracted by the many other ideas we’ll be discussing throughout a project. At the end of the sprint we can evaluate what’s the next highest priority. This allows us to focus and adapt iteratively.

Project Planning

We forecast our projects and our teams with our Team Utilization tool. This shows who’s working on which teams and how much time is allocated. Since we work with many different customers, projects, and Labs, we need to make sure people and time are properly forecasted. Projects are forecasted right before a Statement of Work is drafted for a customer, to ensure that the team will be ready.

Project Kickoff

Project Kickoff is always an exciting time. New ideas and lots of opportunity lay ahead. Here, the most important thing is for us to understand and agree on the primary business motivations for this project. The who, what, where, when, and why of the project. Our project charter will encapsulate all of that information so we can use it as our guide throughout the project, such as business objectives, success criteria, stakeholders, milestones, and risks.

Backlog Grooming

The first step in any work is to define what needs to be done. That’s what the backlog grooming step is for. In product strategy and charter we decided on our business goals with a validated set of hypotheses that would achieve those goals. The next step is to break down our hypotheses into specific, implementable items, called user stories.

User stories are a structure to define who needs to be able to complete what action, for some goal. They’re usually written in the format, “As a <User>, I want to <perform some action>, so that <I can complete some goal>”

The product owner is responsible for keeping the backlog full of work to be done and prioritized in order of importance.

Sets of user stories around a similar function will be grouped into Epics.

Sprint Planning

At the start of each sprint, the team meets to discuss the next round of work to be undertaken. They pull in items from the groomed backlog and estimate the effort required, with a process such as planning poker. The team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog. This meeting should also flush out the details of the work that needs to get done, by setting acceptance criteria and clarifying any questions that arise.

To decide how complex a feature will be to develop, we use the fibonacci sequence. The sequence looks like this: 1, 2, 3, 5, 8, …. The main benefit of the Fibonacci scale is that enough separation exists between the numbers to prevent the team from squabbling over slight differences. For example, if the scale was 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, team members might debate whether a feature was a 7 or an 8. It’s easier for team members to reach agreement if the scale jumps from 5 to 8.

Daily Standups

Typical daily standups occur everyday of the sprint. Most typically these standups are early in the day, last no longer than 15 minutes and consists of three questions:

• What was done since last time?
• What will be done next?
• Are there any blockers?

Commonly there will be questions, comments, or blockers to discuss, and then we can take those offline to solve.

Scrum meetings are designed to be quick and efficient, so we can maximize the amount of time spent doing the work while also keeping communication open.

Sprint Review

At the end of the sprint it’s time to show off the amazing work that was done. The team will take turns demonstrating workable product to the rest of the team and stakeholders, and get immediate feedback from all. That feedback can be used to answer questions or may be turned into tasks for the next sprint.

Sprint Retrospective

Retrospectives are a magical part of the agile process. At the end of each sprint, the team gets together to discuss what went well, and what didn’t go well. The team will then brainstorm how to solve any issues that are identified, and make sure to keep up the things that were good. Every product, team, and scenario is different, and therefore each project will have it’s own unique set of constraints. Through retrospectives, future sprints are tailored to the most efficient and enjoyable process for everyone.

Project Retrospective

At the end of a project, we sit down to pat each other on the back and reminisce. It’s an opportunity to look at the big picture of a project and identify what we learned. Did we try something new that worked really well? Let’s consider doing it for every project. Was there a specific difficulty that we had trouble with? Let’s be prepared for it next time. We collect feedback from our customers, and write about what we learn.

Agile Terminology

User Stories

Short, simple descriptions of a feature told from the perspective of the person who desires the new capability. This is usually the person who will be the one using your app once it’s on the App Store. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.

Example 1: As an (instructor) I want (to be able to markup videos using free draw to show problem areas in the swing,) so the (student will know what areas of their swing to work on.)

Example 2: As a (developer) I want (to research if we can associate multiple email addresses to one user without knowing their UID) so (we can have better analytical accuracy)

Definition of Done

Although a seemingly small aspect, Definition of Done is a crucial factor for successful agile teams. It ensures quality upon completion and sets a clear standard for the team to follow up to delivery. Agreeing on a definition of done is important for the product team due to the inevitable complexity of the software development process. New requirements and possible paths forward are constantly presenting themselves. By agreeing on a Definition of Done each sprint the team is able to focus on a point that isn’t moving. If requirements emerge over the course of the sprint that are outside of the scope of the original Definition of Done, these are added to the product backlog.

Story points

Story points are helpful because they allow team members who perform at different speeds to communicate and estimate collaboratively.

One developer may be highly proficient in backend work and think that a story takes 5 hours. While another developer, that is not as familiar with the work, is thinking 8 hours. When the story in question is compared to another story, they can both agree that it is twice as much work to complete.

This is where story points come in. The abstracted story points allows them to collaboratively agree that the backend story is twice as much work as the other story, devoid of the difference in time it may take each individual developer to complete.

So, when asked to estimate, the developers compare the new backend story to the already estimated story (let’s say it was estimated as 1 point) and agree it is 2 points.

In this way, story points are still about time (effort), but the amount of time per point is not pegged to the same amount for all team members. We can effectively cut out any back and forth that can occur when striving to negotiate hours or days between team members and allow them to collaboratively estimate without bias.

Acceptance Criteria

Good acceptance criteria should define the point when a story or piece of work is completed and working as expected. The language used should be expresses clearly without ambiguity. It’s good practice to write as if you are in your customer’s shoes, using their vernacular.

Think what. Not how. Acceptance Criteria should state intent, but not a solution (i.e., “A user can approve or reject the application to use their phone’s camera” rather than “A user can click a checkbox to approve the application to use his phone’s camera”). The criteria should be independent of the implementation, and discuss what is expected, and not how the functionality will be implemented.

MVP

Minimum Viable Product (MVP) stems from the lean methodology. It is considered to be the simplest, functional product that can be released and distributed to consumers. That alone can sound like a risky exercise so here are some of the specific criteria our MVPs must adhere to prior to release:

• The product must have enough value that people will use or buy it initially.
• The product must have future potential that it can retain and enable continued use from early adopters.
• The product must provide a feedback loop to guide developers through future versions.

We benefit from this approach because it lets us build products that will adapt to the users needs and that can shift rapidly without development upheaval.

For instance, we could build a product that was feature rich and had what we thought to be everything, in the hopes that would maximize our clients success. The problem is we wouldn’t get a lick of feedback until we had spent a lot of our time and our clients money to build all those features. We won’t begin to get feedback until we have shipped and only then would we know if we were on the right track. Now let’s be honest, by that time it is way too late!

How we do project scoping?

Our goal is to work within your budget to get you as quickly as possible to the point where you find that your product is the right fit for the market. This idea is often referred to as building an minimum viable product and has been popularized by the lean startup movement.

One important part of the idea of building a minimum viable product is to separate features from end user goals. End goals are the lifeblood of the birth of a good app — features come later.

In the early part of the process it helps the development team work quickest if you focus on what users need to be able to do with your product and why they would want to do those things.

Once we’ve hashed out those basics, our team will help you work towards building an app that will accomplish those goals.

What is a Bug?

We see a bug as a problem causing a functionality to crash, produce invalid outputs, no output or unexpected functionality.

Bug Severity Levels

A bug is considered a Blocker if…

• A bug is a blocker if it causes the app to…
• Crash
• No longer respond
• Leaves critical functions inaccessible
• There is no workaround

A bug is considered Critical if…

• Defect prevents a key feature from working as designed or meeting functional requirements.
• Testing/experience can continue with workarounds.
• May block minor features and severely hampers user experience.

A bug is considered Minor if…

• Defect leaves Product fully functional.
• Issue can be easily worked around.
• Does not follow intended design and is an annoyance to user experience.

A bug is considered Trivial if…

• Defect leaves Product fully functional with no need to work around
• Does not follow intended visual design and is an aesthetic annoyance to user experience.
• Some examples include, but not limited to:
• Grammar
• Spelling
• Aesthetics
• Cosmetic
• Animation
• Formatting
• Alignment
• Keyboard behavior
• Minor usability annoyances

QA & Testing

The primary developer working on the feature will test its implementation and functionality as the sprint progresses on their own. Once he or she is finished, the user story will be passed off to another developer to peer-review the implementation approach and make code quality suggestions. The initial developer will then go back and make any changes suggested by the second developer, after some discussion. The primary developer will then send out a beta build to the team, and have a non-developer review the functionality of the feature and confirm that it meets the Acceptance Criteria. Finally, at Sprint Review, the client will have the final say as to whether feature meets our mutually agreed upon Definition of Done.