Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm currently at the beginning of a build. We are requiring a lot of back end functionality around Clients/Users/Groups/Roles.

However, these aren't required for Sprint 1 which is acting as a MVP release. But I want to ensure we are preparing for this enhanced back-end in the future.

This is easiest by defining an interface to the User Management system without actually building all of it yet. How would you organise this in a Scrum project environment?

Obviously, in order to decide how the interface needs to look. We need to decide on it's functionality. But in doing so, we'll be getting very close to speccing the entire thing out. Which isn't required for several months!

(This is a Team Foundation Scrum 3.0 workflow for those interested)

share|improve this question

I assume that since you want to prepare for the work you believe that the back-end functionality is bigger than could fit into a sprint? (i.e you could not build it in the sprint where the functionality is required)

If that is the case, then I would suggest taking the overall back-end functionality and breaking it down into multiple independent pieces that are small enough to be completed inside of a sprint. Take each of these pieces as a story, and build out the back-end functionality for each piece sequentially across multiple sprints, evolving the back-end architecture and user management UI as you go.

For example, you may just start with something as simple as a Login story, which requires the back-end to have the concept of usernames and passwords. You don't need to worry about all the roles and groups yet, just start with something.

There will be refactoring along the way, you don't need to spec it all out up front. That doesn't mean you shouldn't think about the architecture and your eventual goal, but you can drill down to the details as needed. Perhaps on user story 5 you realize something in user story 2 was done wrong. When you estimate story 5, make sure to include the effort to rework what was done in story 2.

One of the easiest ways to support this in a demo is to think about what the high-level user goals are for managing the users. In your demo, show a user accomplishing one of the goals. The goals may be something like this:

  1. Login
  2. Edit My Profile
  3. View other users in the system
  4. Assign roles to other users
  5. Manage groups
  6. Secure group management
  7. Secure user management

Those 7 goals might become your stories (or you may group some together depending on their size and your own personal preferences). You can then tackle them incrementally across your sprints, planning so that all of them are in place by the time you reach the sprint where all the functionality is needed.

share|improve this answer

Taking an agile approach to this I would not do as you suggest and build the mock interface prior to starting work. I would evolve the interface as you progress.

First of all focus on the most valuable stories (and it is VITAL that these meet INVEST principles).

The tricky bit here is how you build your stories, and getting the definition right with both the team/s and the product owner is essential. This will make or break the project. There are two options I would consider for this, lets take for example the story 'As a user I want to log-in'. (I know this is a terribly formed user story, but it gets my point across simply). There are two options for defining this, and either approach could be better depending on how your team/teams are working on the project:

  • The 'pure' Scrum option - how I would do it if you are a single Scrum team.

Specify technical requirements as acceptance criteria of the story. Eg. The login must be secure using XXX encryption, password strength etc.

As you build this story you design the aspects touched on by the story - eg. A users and passwords in the DB, and all the required fields. If another story in the future means this will need refactoring, this is included in the size of that story. Also, unit tests are essential to ensure that refactoring doesn't break existing functionality. This is probably the best approach if there is only 1 scrum team on the product, as it is best to get everything production quality as you go.

  • The Commercial Scrum option - how I would have done this in a company with multiple Scrum teams, that are not purely cross functional.

Ignore the tecnhical requirements, and separate them into a separate story. Eg. a 'login' button is created that always passes, and lets you into the system to continue. This means the 'front end' team (or sprint) can continue working and delivering further value, and a separate story holds the technical requirements and DB design of logging in. It is vital that everyone knows the functionality doesn't exist yet.

The main advantages to the second option are:

  • One team can build the UI while another team builds the DB. They can then carry on with other stories.
  • Stakeholders can see progress much earlier and get a feel for what you are building, which can influence design from an early stage.

The big risk is people believing progress is further than anticipated, because you have something that looks 'nearly done' but doesn't actually deliver value. This is why the first option is more 'pure' Scrum.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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