Developing a web app from a design, how should I split the work up?

Question

I would like to know how I should go about splitting up the work into tasks/stories for developing a web application?

I created an in-house organization tool for the company I work at just to make things a bit easier for our day to day operations. It was very rough and ready, I developed it without much planning and just changed it based on feedback.

One of the partners here has decided that he wants to take the application outside of our company and sell it to others, we've gone through all of the planning stages and we've had the UI designed (due to some complications, I have not been able to start until after we received the UI design). I've planned out all of the models and know what features we need but I don't really know where to start now. I'm not sure how to go about breaking the development up into manageable stories or how to plan the timeline of the development so I would like to know how to do those things correctly.

My current plan is just to list out all the core features of the application, things such as "edit organization details" and just start coding those one by one but I'm not sure if this is the best practice. I want to do this the right way so I can be trusted with more responsibility with next project.

For a little bit of extra info, it will be just me developing the app for now, I'll be using Rails and I try to follow a TDD style.

Answer 1

There won't be any one single answer to this, although there seem to be those that think there is. They may be right, but my gut says "nope". Here are some opening thoughts.

I) General Goals for Life During the Development Process

The approach you choose must allow you to fulfill the following goals:

1. ALWAYS have something to demo to stakeholders
2. ALWAYS have the next thing "cooking" as well
3. ALWAYS be able to answer stakeholder questions regarding approximately when they'll be able to see a demo of such and such a feature.
4. ALWAYS be able to be flexible should stakeholders require you to change the implementation sequence.
5. Be able to distribute work should the opportunity arise.

II) Create a Team Environment at the outset

Even though you are the sole developer right now, be certain to set everything up as if there will be an entire team working on your project. It's surprising how fast we tend to lose the basic disciplines when working alone - always work as if you're part of a team, even if the other members are "virtual".

There are some design and implementation decisions you'll want to make first.

III) Feature Set Sequence

Do you intend to present the product whole and complete on the first "live" release, as opposed to doing it iteratively? If iteratively, you'll want to determine the feature set that comprises the minimum viable product (MVP). Then you'll want to set up (or suggest to stakeholders) the feature increments (milestones) for the first few cycles. Once that's done, you'll have a schedule, and be able to fall into a design/develop/test/release cadence that delivers expected results in the expected timeframe. That cadence, consistently followed, is very important in building stakeholder confidence. Even if the initial release must contain all the features, you'll still want to take an iterative approach, identifying the MVP for yourself and incrementally adding features. Why? Because right from the first minute you begin, your sole focus is that first demo.

IV) Architecture

You already have a technology stack chosen. Ensure that your choses stack supports:

1. Fairly rapid prototyping
2. Fairly easy testing
3. Automation of every phase of the cadence.

V) Epics, Stories, and Sprints

Just because you're working alone and are your own scrum master, don't skimp on the Agile Disciplines and Rituals. Although such rigor will feel ridiculous at times (why on earth should you have a daily stand-up with yourself?), producing the Agile deliverables will give stakeholders a fairly reliable view into your work. This creates (justified) confidence and says (truthfully) that you really know what you're doing. Forget creating an impression - concentrate on doing the right thing and that will create the impression for you.

Opinion Section

Some shops take the approach that the whole project is an Epic, and each feature is a User Story. I've experienced environments where the alignment between Story and Sprint was strictly enforced, and others where it's much more lax. Personally I like to align Epics with Features in an Epic(Feature)/Story/Task/SubTask approach, wherein Story and Sprint are aligned. That lets us complete one Story in one Sprint, and permits the assigning of Story points more accurately. Tasks and subtasks make it easier to distribute the work, even though as of right now, there's no-one for you to distribute it to ;-) So what? It's still a good idea.

I hope these few thoughts help you toward a good start.

Answer 2

I would like to know how I should go about splitting up the work into tasks/stories for developing a web application?

1. Start with setting up the framework for the code, build scripts, continuous integration, and automated deployment. To do an end to end test you need at least one page; since nothing will work, the first page should be the error page.

2. Next you will need enrollment and authentication. You can't do much without these!! Start with basic flows ("happy path") and then add alternative flows, e.g. bad password or user locked out.

   Once #2 is done, pass the site to your penetration testers or get AppScans done in parallel with #3 and later.

3. Next, build a page that demonstrates your layout and assets. This is where you come up with layout templates, responsive behaviors, and font and color standards.

   Once #3 is done, pass the site off to your UX professionals or stakeholders to ensure it is all in order, and get your first round of cross-browser testing completed so you can detect any structural problems.

4. From this point forward, the order in which you implement features is determined by the business stakeholders. In general you will want to start with basic flows and then add alternative flows afterward.