1

We are in a group of 3 students in computer science, and we are making a website for our customer.

First, we make a design for the website, and it took us 2 weeks to finish it. We converted it into HTML and CSS for another 2 weeks. We did it this way because some of the group members are not familiar with the tools we are using so they spend time in learning new technologies from PSD to HTML/CSS. When we have the forms we start the coding part.

The motivation behind in creating such a story is to fulfill the needs of our customer for their website.

We have 4 sprints:

  • 1st sprint is design (2 weeks)
  • 2nd sprint is html and css (2 weeks)
  • 3rd sprint is database (1 week)
  • 4th sprint is coding (3 weeks)

How can I make a story pointing from the 1st sprint to 3rd sprint? I need to make a burndown chart for this, but I cannot figure out what to do.

3
  • Hi and welcome to PMSE! To improve the answers, it would be great if you could add some more details: What kind of story are you talking about? What is your motivation behind creating such a story? Why do you need to create a burndown chart for this? – Tob Jun 23 '15 at 14:14
  • Hey Phamela, I edited this post to include details from the comments. Can you please clarify if you intended to use Scrum for this project or are you simply borrowing components from it? Thank you. – jmort253 Jun 23 '15 at 16:04
  • We are intended to use Scrum, thank you for editing my post. – Phamela Hoffmann Jun 23 '15 at 16:26
2

If all you are looking for is a burn down chart to measure progress I would suggest breaking each section into tasks, and not worrying about stories. Each of these tasks can be estimated in hours, and you can burn down the hours of completed tasks. This will allow you to track progress and fit in with your schedule.

User Stories is a concept that doesn't really apply with how you have split your work - as they are end-to-end pieces of user functionality spanning all of your 4 sprints. If you create user stories you will have not have completed any until the end with your current schedule, making them useless for tracking progress.

0

What will help you in the close future is not the application of a specific framework bus some basic aspects. Those aspects underly almost all frameworks:

  • Know your requirements. It doesn't matter if you document them by User Stories or atomic requirements
  • Make a project plan / task list / backlog, how to realise those requirements (sounds like you have this already)
  • Stay transparent within your teams regarding current tasks, finished tasks, and upcoming problems by introducing short talks on a regular base using your project plan / task list / backlog
  • Try to foresee upcoming problems by thinking about possible risks within your team

Without knowing too much about agile PM those steps will lead you to a classic waterfall execution, maybe with some agile aspects, e.g. daylies. Regarding your (estimated) experience and your project due date, this won't be a bad choice.

By the way, as usual when it comes to complex topics. All the aspects I highlighted here are a field of study for their own. If you find one interesting, just dig deeper googeling the buzz-words :)

-1

You are not doing Scrum

Based on your question, it doesn't sound like you are doing Scrum at all. In Scrum, the goal of a development team is to produce a potentially shippable product increment that can provide real value to end users. If you're splitting up sprints into design, HTML/CSS, database, and coding, then you are not in fact doing Scrum but are actually doing waterfall.

Instead, your product backlog should contain user stories that represent problems users are having that can then be taken by the development team and turned into working software. To do this, a single user story could be decomposed into all of the above tasks, database, design, HTML/CSS, coding, etc, but only for a single user story, or for a number of user stories that the team can commit to completing in a single sprint.

To clarify, in Scrum, all of these activities are done every sprint, not split up into different sprints.

Burndown charts

As for your burndown chart, the chart itself should represent the amount of story points that are not completed yet in that sprint. This is based on the effort estimation the team does during the Backlog Refinement Meeting with the product owner.

A user story is not considered "done" until all of the tasks are completed that meets your acceptance criteria and definition of done. Again, this means design, coding, HTML/CSS, database, etc must all be completed in order for a user story to be marked as done.

Learn more about Scrum

Moments ago, eight of us in our office just completed the Certified ScrumMaster training from the Scrum Alliance. Before starting Scrum, I recommend a lot of focus on learning what Scrum means. A good place to start is Jeff Sutherland's book Scrum: The Art of Doing Twice The Work in Half the Time, as well as the Scrum Guide. If you're really serious, I highly recommend taking the Certified ScrumMaster course.

6
  • Thank you for reminding me and explaining it, I ask my teacher about it actually and she said its ok that I do like what I mention above but then now you explain more and its a good comments I got from you =) – Phamela Hoffmann Jun 23 '15 at 14:18
  • The original post never claimed they are doing Scrum, although the tag could be removed. I also don't think a reply should be advertising the Certified Scrum Master course either. – SpoonerNZ Jun 23 '15 at 15:53
  • @SpoonerNZ, after seeing the comments, I'm thinking this answer may need to be modified to address the question in its new form. As for the Scrum Alliance's CSM training, I am not affiliated with it at all, nor am I affiliated with Jeff's Scrum book or the Scrum Guide. Check out our help center's guide on spam and self-promotion. – jmort253 Jun 23 '15 at 15:58
  • Also, do other Agile methodologies use the term "sprint" and "story points"? I thought those were specific to Scrum, but that may be an incorrect assumption. – jmort253 Jun 23 '15 at 15:59
  • A lot of what is commonly considered part of Scrum is actually just concepts often used with Scrum. Have a look at the Scrum guide (scrumguides.org/scrum-guide.html) and you will see a lot of this is actually NOT scrum, but still useful to use. Apologies if I sounded rude, but I believe there are much more valuable certifications that the Scrum Alliance training, certainly within the UK where I am based. – SpoonerNZ Jun 23 '15 at 16:02

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.