1

I am in the process of starting a website build and previously it has just been a case of :

  1. Get designs
  2. Start implementing site by incrementally building the style and functionality

That's it. No real plan it just sort of happens and gets there in the end. For my upcoming project I would like to implement a more structured approach using agile and start by creating a product backlog etc at the start.

But, im struggling to see how this should look. Should it be broad as in :

  1. Frontend Development
  2. Backend Functionality
  3. Testing

Or should these be split into areas of the site such as...

  1. Site header
  2. Site footer
  3. Homepage
  4. Contact page etc

or split into functionality

  1. General site structure
  2. Homepage carousel
  3. Contact form functionality
  4. Contact form frontend

How detailed does my plan have to be?

  • When you say "my project" does that imply that you and only you are doing the work? Is this paid work? Do you have stakeholders? How involved are stakeholders willing to be? What pain did you experience that led you to want to change you methodology? Identify what pains you are trying to solve before figuring out how to decompose requirements. – Andrew Clear Mar 18 '13 at 20:07
3

I hate to be the type of person who says, "It depends" - but, it depends.

I tend to divide things between project-specific concepts and generic concepts. For example, I recently worked on a site which displayed a lot of data in the form of progress bars in two different areas of the site. So, three tickets/stories get generated:

  1. Widget 1 consisting of progress bars, table, etc.
  2. Widget 2 consisting of line chart, progress bars, etc.
  3. Progress bars

Now, there are dependency relationships for these tasks. In the example, the two widgets cannot be completed until we finish creating a way to make progress bars (a Finish-to-Finish relationship between the progress bar and the other two tasks). Therefore, in the backlog, the progress bars actually get the higher priority.

It also depends on what you are responsible for. If your only focus is front-end and UI components - focus on that. If you're doing everything front, back, and all points in-between...you'll probably want to do something different.

A general rule of thumb I have adopted over the years of working on the web and in other development areas is to start with a general task: Create 2013 Version of Website, for example. Then try to estimate the duration and complexity level - if I can. If I can't estimate it because it is too vague, I start filling in details (maybe, build header, build footer, build single page template, etc.) - basically atomizing tasks, similar to creating a WBS (http://en.wikipedia.org/wiki/Work_breakdown_structure). When all/most of the tasks can be estimated to take one working day or less to satisfy a definition of done (for me this is unit tests, if applicable; cross-browser compatibility; documentation; etc.), then I stop atomizing them.

What I have found, by following this rule of thumb, is that the stories pretty much write themselves and the backlog tends to be more complete than if I tried to shove a project and its requirements into some predefined structure/convention. So, go back to the original example we might end up with a break-down like this:

1. Create 2013 website
    1.1 Widget 1
        1.1.1 Progress bars (FF with 1.3)
        1.1.2 Table with data
    1.2 Widget 2
        1.2.1 Progress Bars (FF with 1.3)
        1.2.2 Line chart
    1.3 Progress bars - split-out and promoted to a higher-level of our WBS
        because it's used in multiple places

(I am new to this StackExchange site; so, pardon me if there is a better way to visualize that.)

In conclusion, to answer the question indirectly but concisely - it depends. To offer the most useful/pragmatic recommendation I have found over the years - don't come up with a template before you start documenting tasks - this leads to possibly trying to fit a round peg in a square hole. Instead, add a backlog item at the highest level possible - start building a list which fleshes out this abstract concept at the next level down - then, continue cultivating the backlog by breaking out tasks into 1 day's effort bits and reusability. Finally, use dependencies to help prioritize the backlog and choose which items have the most value - in our example, the progress bars have the most value; therefore, are the most important.

Hope that helps.

0

You're right to consider multiple aspects for web development.

If you have an external client who is giving the final verdict on the design or functionality, you should separate those elements out because those requirements can change quickly.

That said, most web development teams use flowcharts and wireframes to mark the infrastructure for the web site and a versioning system for tracking code changes. The wireframe gives some stability to your development of frontend before considerations are made for specific graphical elements like colors/fonts, while the versioning system (usually dependent on functionality) helps track the changes for functional requirements.

Another consideration is dependent on what features you'll show your customer at specific time intervals. The order in which you assign tasks and finish them (each feature should go thru development and testing) is up to you. It is also ideal to have development side testing performed prior to production level tests of each feature. Especially true for data heavy sites.

-1

In my view your project is a great fit for trying out Scrum.

I agree to your current approach of incrementally building the site. Having used Agile for years, my recommendation is to break your requirements into testable features or functionality (product backlogs). Build milestones (Releases) around features - first milestone could be to build bare-bone site structure with graphics, logos, theme, and menu with placeholder pages. Further you could plan to build one concrete functionality per milestone. A Release would contain one or more sprints.

Once you have product backlog, you may want to allocated features into sprint backlog, each sprint of duration 3-6 weeks. Again, the goal is to deliver something at the end of sprint that is testable and does not break. This way incrementally develop and release fully working set of functionality.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.