Tag Info

New answers tagged

0

According to Tuckman's Stages of Groupdevelopment you risk that your team drops into the "Storming Phase" again and again. This is not desired to happen too often, because of the lack of performance in this group phase. You can try the following to address your problem: The moderation of the retrospective does another Scrum Master.


0

Another factor: Even if your story points are the infallible word of god a change in the points as you split things up is likely due to roundoff. Not all 1-point stories are exactly the same size. You break a 10-point story into 8 equal parts--you have 8 1-point stories but that's because you can't have a 1.25 point story.


1

The bigger the story, the less accurate the estimate will be. When you're talking about a 20 point story, that could easily reduce down to four 10 point stories, or two or three five point stories. That estimate of 20 is so large as to be almost as useless as a coin toss. All 20 really means is "it's too big"; the number itself means nothing. The whole ...


1

No. When you break up a task into subtasks there will be now be additional: time to context switch between each piece time to record each small story in the issue tracking system setup / teardown of configuration and test data Also if you using the fibonnaci series (or basically anything other than every number), then breaking down a 13 point story ...


4

Not necessarily. The reason that higher possible story point estimates are usually farther apart (like in the Fibonacci sequence) is that estimation is less accurate, so it's not worth distinguishing between e.g. a 13 and a 14. But after analysis to split the stories, each part can be estimated with higher accuracy (that's one of the main advantages of ...


2

No. The new numbers should not be compared to the old number. That's not thinking of story points the right way. For example, if I were to split up an 8 point story into 1 point stories, I might get to 15 to 25 1 point stories. Is this because my team's definition of 1 point or 8 points is wrong? No, we defined 1 point to be a story which could be done in a ...


1

Setting aside such issues, are case-studies (of other teams' effective uses of Scrum) an effective way of swaying reluctant team members? (particularly on the issue of efficiency) Or, is there something better than case-studies? Case studies really are a poor substitute to general experience and even if people read them, it likely won't make any big ...


2

Unfortunately there's no great answer to this question. Physical Board A physical board has advantages. It's effortless to radiate, a great place to have conversations around, and promotes a pull-based workflow. It's completely customizable and you can use whatever rules and flows you want without any impediments. Edits to current work are easy, no ...


1

This should not work alright. The dual-maintenance that you mention is not only an annoyance, but a problem that may lead to work duplication while also needing extra work just for syncing the board. I'm not sure if you remember the CAP theorem from any Databases course, it basically says that your model will fail to be correct, or fast enough if you want ...


3

I am currently working in a Scrum team that consists of a mixture of on-site and off-site developers. The lessons I have learnt so far here are: You really need to use a digital board. We started out using a physical board, using a webcam to show the board to the off-site team members. The biggest problem here is that you can't get a good overview of the ...


1

There is something better. It is called 'authority'. Product owner decides what goes first and what goes after. However, it's expected from developers to communicate to product owner that some things might be more efficient doing one way or another. That being said, authority is still the product owner, and based on the input from developers, product owner ...


1

At which point to the tasks get assigned? Product backlog items are added to the sprint backlog by sprint team members during the sprint planning meeting, in order of priority (which is determined by the Product Owner) What does that actually mean for the sprint 1 and 2 planning? (i.e. the what to do and how to do it topics of sprint planning) The ...


0

The sponsors, developers, and users should be able to maintain a constant pace indefinitely. A sprint means... run at full speed over a short distance. Using the term sprint is still compatible with the (Agile) ability to maintain a constant pace. A whole group maintaining a constant pace does not necessarily mean that they are all moving at the ...


0

Any suggestions on how we get the team bought in to finishing the sprint by the end date? Strictly speaking, the Sprint is finished by the end date, whether the Sprint Team has completed all the Sprint Backlog items or not. You don't need "buy-in" to finish the Sprint on time... You need "buy-in" to actually follow Scrum. Why do we think it is ...


0

What is the recommended approach to fix this when we realize our error Estimates are estimates. I would not view it as something to be fixed, when it happens. I would view it as an opportunity to diagnose the reasons and improve your future estimates. Since the aim of Scrum is high quality increments of deliverable product, you want to stop and assess ...


0

At some point during each Sprint, you should have a Product Backlog Refinement Meeting. At this meeting, you ensure that the top portion of the Product Backlog is broken down sufficiently for items in that portion to be added to the next Sprint Backlog. If Product Backlog Refinement is managed well, then the Sprint Planning Meeting can be more efficient. ...


0

This could be a beneficial practice if the "rotation" is done in the form of one Scrum Master "shadowing" another, rather than attempting to take over. In that fashion, the "new influences" you spoke of could be shared without the inefficiency of an actual hand-over of responsibility. Practically speaking, this might be accomplished, for example, by a pair ...


1

While the question, as posed, has broad scope, the core issues seem to be: ...Scrum assumes that there is no 'requirements freeze'... ...embedded system due to tight coupling with hardware need upfront specification... Scrum aims to produce high quality increments of a deliverable solution. It does not aim to minimise re-work or minimize time to ...


0

While significant supporting motivation and explanation was provided, the core question seems to be: ...how do you make this work effectively when there is distance between the developers and the users? To me, this challenge is not unique to Scrum. Effective collaboration between geographically dispersed individuals is a common challenge. While the ...


1

Does the software team has any influence on the hardware specs? Or is it purely the other way around (hardware team dictates low-level software interface)? In the latter case, a HAL (hardware abstraction layer) person must sit with hardware team to write the low-level software interface; GUI team can work at their own pace, possibly using Scrum or any ...


1

I don't have personal direct experience in embedded systems - but I do understand waterfall and agile and the differences between the two, as I am sure you do too. I have also discussed this issue - of applying Agile in industries such as embedded software development, semiconductor design/ development, etc. with friends who work in those industries - so ...


1

Scrum is not concerned with requirements freezing or not. Scrum works equally well if you start with 100 stories in your backlog that never change, or 5 stories with more being added/changed all the time. Scrum is supposed to be an iterative process and it requires a totally different mindset than more traditional waterfall models. Technically with Scrum ...


1

If you are faced with the work needing to be re-done, you re-do it. Re-doing the implementation of a product backlog item does not necessarily require any user story to be re-written. The motivation to re-do the implementation may not have had anything to do with a change in the user story. Re-doing some implementation also does not necessarily require a ...


10

At the beginning of your sprint you should have a sprint planning meeting. This is where your team decides which user stories to deliver that sprint. At the end of the meeting you should have a reasonable and prioritized sprint backlog. Your developers should then pick tasks from the top of the backlog. When they finish their current task they return to ...



Top 50 recent answers are included