The much anticipated Django 2.0 was recently released and we are updating Pinax apps, client projects, and our own sites. This offers the perfect opportunity to share our process and some of the most common issues.

Recently I updated eldarion-ajax to have more robust tests along with 100% test coverage. I wanted to get to this point before I venture into some potentially aggressive refactoring.

For a long time, we used TravisCI and Coveralls for executing lint checkers and tests and tracking our code coverage. These are fine tools but we've recently switched to CircleCI and CodeCov. This is our default setup for projects.

It can be fairly common to have situations where your users need to quickly add items to a list, edit those items, and perhaps even sort them. Ideally, we can keep the user focused on their data and tasks rather than how to navigate the software facilitating the work.

Code coverage is an important aspect of good engineering practice. Without it, you are flying a bit blind writing tests.

In the previous parts we have learned how to write stories, groom and point them. Everything up until now has been done to prepare us to be able to plan a sprint.

Before you add a story to a sprint it should be pointed. Pointing a story means assigning a number that represents complexity to it. Metrics like velocity are driven by these points.

It is important to constantly be refining your backlog. This is accomplished through time-boxed meetings where the team performs an activity called grooming.

Every successful Scrum project starts with a solid backlog of items. Developing a good backlog requires discipline and vision.

We have run a lot of successful projects with Trello following a rough Kanban-style approach that focuses on continuous delivery. However, as we have taken on projects that involve more people and have longer timelines, the process and tooling left us wanting more.

In building wine.study, we quickly got to the point where we were experiencing a development bottleneck in the construction of components. This bottleneck occurred due to a number of reasons. We solved it with a live style guide.

Previously, we discussed the 5 reasons you should consider React, but it's not always the ideal choice technically. Let's outline when and when it does not make sense from a technical feasibility perspective.