3

I am making an e-commerce project that has a dashboard module. Instead of having one sprint for the dashboard module, my advisor said I should split this module realization into two different sprints: one for the dashboard API, and one for the dashboard UI.

I am still new to Scrum and this is my first project using it. In term of coding, I will be doing the APIs first, then build the front end next.

I was thinking of something like the following.

Sprint one - dashboard API will contain:

  1. sprint backlog
  2. use case diagram
  3. class diagram
  4. mock ups
  5. sprint retrospective

Sprint two - dashboard UI will contain:

  1. sprint objective
  2. sprint review

From a project planning perspective, is it wrong to have one sprint for the API and another sprint for the UI?

3
  • 1
    This question is unclear, and currently lacks sufficient information to receive anything other than purely subjective responses. To avoid closure, please clarify your question and provide a little more detail about what work you're trying to decompose and why.
    – Todd A. Jacobs
    Jun 15 at 14:12
  • 1
    While I agree with @ToddA.Jacobs, I also wonder if the plan you've proposed will result in deliverable value to the customer for each sprint, and if each team will be able to be responsible/accountable for the delivered value? Or will this plan wind up with the manager managing the cross connecting dependencies, which will undermine the team's ability to self-organize.
    – MCW
    Jun 15 at 14:58
  • 1
    Is this a solo project? If yes, why are you requested to do it with Scrum if you're not familiar with the methodology? Normally, you'd learn to do Scrum by being trained as a Scrum Master or being part of a Scrum team as a developer. If you have an advisor ind such a nonstandard setup, they should be the right source of information on how to proceed, they can't possibly expect you to know that stuff when you're new to Scrum. Jun 15 at 15:29
2

By the way you are describing this project of yours, it seems to be a "one time thing" and your advisor is suggesting an iterative and incremental approach by using Scrum, but didn't explain what Scrum is. I also have the feeling that they don't themselves know how Scrum works. I suggest you read the Scrum Guide to figure out what Scrum is all about.

The idea is to have a functional piece of software at the end of each sprint. Be it completely implemented or just partially implemented but enough to learn, gather feedback and figure out what is needed next. It seems you already planed out how you will do your work and now you are just trying to fit it in two sprints. Your approach is incorrect. Not to mention that the structures of your sprints are wrong (each sprint has a sprint goal, a sprint planning, a review, and a retrospective; you can't spread these activities like you did in your example, over multiple sprints).

You should think about what's the minimum functional thing you can get working into the first sprint (or even first few days of the sprint), then think what else to add to that, and then repeat until you have implemented the full feature or something you are satisfied with, or anything that can be reviewed at the end of the sprint.

Each Sprint end is an opportunity to inspect and adapt. And you do so by looking at working software, not class diagrams, use case diagrams, building an API in one sprint and the UI in another.

One other thing (which goes back to your advisor possibly not understanding Scrum) is that this seems to be a solo project. Scrum is not the best choice for a one man team. You can still use the incremental and iterative approaches by applying the principles themselves, but without the overhead of the Scrum framework.

2

We eat a piece of cake vertically, not horizontally, a user story is like a bite of cake, when we eat a cake horizontally we don't feel the perfect flavor, what I mean here, that the user story represents value to the customer. Do you think that "use case diagram" is valuable to the customer or have more value from than landing page?

enter image description here

find more

Your "Sprint one" doesn't offer any valuable increment to the customer, it is just team tasks, if you decide to follow Scrum, you should have at least PBIs, these PBIs tell you what you should increment.

anyway you are closer to be a mini waterfall because you don't adhere to the agile manifesto "Working software over comprehensive documentation" note, you consume full sprint to do team task rather than customer business value "

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.