Scrum: task dependency and task for architecture design [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

I have some Scrum problems:

1. Task dependency: Most books I read seem like treating the tasks as independent from each other. One programmer tasks doesn't affect the other's one, thus can be run in parallel. How to deal with task which is depend on another one?

2. Task is based on story/feature/function: There are a lot of ground works before setting up the project开发者_Go百科, e.g. design the architecture, learning the architecture, framework etc. And most functional tasks are depend on this architecture work to be completed. That's Q1 problem. At this time, there will be only one programmer working on the architecture design, while the rest of the team don't have any assign task?

Please tell me how to tackle this problem. Thanks

---

(1) Tasks are the steps towards the goal of a user story, similar to steps in a recipe. In both cases there are dependencies what to do when and in what order. The key is that the team talks about how to split things to work most efficient. This is not one person's job, but the Scrum team's. This happens initially during sprint planning when user stories are tasked out (by the whole team), but also daily as work is being done (daily standup etc.).

The skill is not really about finding tasks with no inter-dependencies as much as it is to minimize the dependencies and to organize things in an optimally for team efficiency. This is the team's responsibility. A Scrum Master's job is to mentor them in this direction.

(2) In Scrum (agile) you don't do architecture up front. That doesn't mean there is no architecture work in agile. On the contrary, architecture is done continuously throughout the whole project. From the start there are loose concepts and containers of ideas how to do things, and later on in the project this shell is filled with concrete architecture, bit by bit as needed by the user stories being worked on.

With regards to learning, this is true in any case, agile or not. In agile you learn the whole time. Not upfront. In the first few sprints there might be much less user stories picked as the team needs to learn new technology and other things, but the essential thing is that something shippable needs to be taken on every sprint. This has several benefits because the team can try both architectural ideas as well as their skills harnessing a new technology. Over time, this alters and the team will have a pretty good idea what the overall architecture looks like and how the technology works to pick more user stories.

My last advice is to not take over any constraints from waterfall like Q1, milestones etc. that say architecture is done by then and then. This is counter-productive and will fail. Stay agile (or not)!