Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
I have confusion in understanding the difference between iterative and incremental software process model?
what is the main reason of making these two software model if they both works same?
It's not that kind of difference to have an iterative process or an incremental process. Models use the terms to describe the process, but there are models that are both incremental and iterative.
See https://www.testingexcellence.com/iterative-incremental-development-agile/
There is a software design principal: Design iteratively, build incrementally.
From Wikipedia:
Iterative design is a design methodology based on a cyclic process of
prototyping, testing, analyzing, and refining a product or process.
...
The process should be repeated until user issues have been reduced to
an acceptable level.
From Righting Software by Juval Lowy:
While the car company may have had a team of designers designing a car
across multiple iterations, when it is time to build the car, the
manufacturing process does not start with a skateboard, grow that to a
scooter, then a bicycle, then a motorcycle, and finally a car.
Instead, a car is built incrementally. First, the workers weld a
chassis together, then they bolt on the engine block, and then they
add the seats, the skin, and the tires. They paint the car, add the
dashboard, and finally install the upholstery.
There are two reasons why you can build only incrementally, and not
iteratively. First, building iteratively is horrendously wasteful and
diffi cult (turning a motorcycle into a car is much more diffi cult than
just building a car). Second, and much more importantly, the
intermediate iterations do not have any business value. If the
customer wants a car to take the kids to school, what would the
customer do with a motorcycle and why should the customer pay for it?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
My team is making the transition to Scrum.
I am facing an issue I still not found on the various Scrum resources I've been studying: how to manage training?
I express myself by example:
my team has 4 developers, 2 of them know nothing about Test Driven Development
the project must be done using TDD
Should I create a backlog item "Study TDD" and use the first sprints so that the untrained developers learn TDD?
Or should I remove the developers from the project until they completed the training? Which is the best practice in this case?
Just send them to the training, and continue your sprints as normal. While they are in training they won't contribute to the velocity, the same as if they were sick or on vacation or just having a bad day. The velocity isn't a goal so much it's an indicator.
You can create a story for training if you want, but it isn't necessary. If creating the story helps, by all means do it. Don't do it just because you think you're supposed to. I've been on teams that liked to track non-product tasks, and teams that didn't. Do what your team decides to do.
In your question you wrote:
the project must be done using TDD
I hope that's because the team decided that, and it wasn't something that was decided for them. The whole point of scrum is to build a team that can make these decisions for themselves.
Well, I will answer YES.
you need to create back log
you need to define test cases and follow TDD
you need to do stand-up meetings and daily follow up
you need to define a team member as scrum master who have best understanding
further, you can engage an online training of transformation expert
Like, I know these guys regarding Agile/Scrum Transformation. http://sparklegenius.com/solutions/agile-transformation/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
We develop products and want to use SCRUM for development. We start with business case, high-level business analysis and technical outline that all contribute to and form the backlog items.
So after a month or so, we have the high-level features captured in the product backlog, keeping in mind it might change. So now we should decide on the team...how should I do that? How to tell whether 2 or 6 are needed, what is the best practice?
Usually SCRUM goes like this:
Depending upon the backlog and complexity of tasks a development team of 4-8 individuals is created which typically includes designer, architect, developer, tester and a scrum master (tasks like: analysis, design, development, review, testing & technical documentation).
You can decide on sprint cycle's length including a separate planning period
In planning period you assign tasks to individuals and the effort estimates based on availability of resources and time
After planning, you track the progress of tasks and update your backlog list accordingly
As SCRUM is supposed to be self organized, there are times when you might need some interaction from project managers or domain experts.
After each sprint cycle, ideally there should be some dedicated time for sprint analysis which can give inputs to next planning phase.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Does the product owner actually vote on the size of the story in Scrum or is it just Dev/QA?
I was wondering, because it does not really seem like having the product owner vote is productive.
In "classic" scrum, the team decides on the estimates and commitments of a story without the PO. The story in the backlog is discussed by the team and the PO and then agreed upon by the team.
EDIT : as nuqqsa and xsAce pointed out, the presence of the PO can be helpful during the estimation session, as he can help clarify the exact requirements and thus make the estimation more precise, but he does not take part in the actual estimating.
The Team (Dev/QA in your question, but anyone who's committing to the Team's iteration delivery (designers, documentation writers are some I've seen) comes to a consensus on the size of each story, and the overall size that can fit into the iteration.
Scrum Teams generally use a 2-phase planning meeting; discussing prioritized stories with the PO, estimating them (which may reveal inconsistent understanding by Team members and/or the PO) using a non-timebased unit (story points, t-shirt sizes, etc.), and then when an agreement has been reached about what will fit into the iteration, breaking the stories down into tasks, and estimating them in the 2nd phase. (It's permissible to renegotiate the iteration commitment if there is dissonance between the the 1st and 2nd phase estimates.)
Hopefully, instead of 'voting' (estimate with the most votes wins), the Team is coming to a common consensus of understanding and effort, so that everyone can commit equally. If it comes down to two next-to-each-other-estimates-on-the-scale-being-used that the Team can't come to a complete consensus on, the larger one wins.
There is an inherent conflict-of-interest with the PO participating in the estimation process. If s/he really thinks the Team's estimate is out-of-whack, then perhaps they do not share the same understanding of what's being asked for, and a few minutes should be spent gaining additional clarity.
Remember the 3Cs of the User Story 'card' -- Card, Conversation, Confirmation. The Card is a promise of a Conversation between the PO and the Team. The PO absolutely needs to be part of that Conversation (can't have it w/o them!), and the PO and Team need to understand and agree upon the Confirmation (acceptance tests) needed.
The Dev/QA decides on the size of story and the associated estimates. Product owner shares the prioritized product backlog with the team and the team decides which items they can complete within the current sprint.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Which organisations are best suited for use of Scrum methodology and why?
Scrum is not a development methodology, it is a project management methodology. Scrum is about managing workload and resources, and removing impediments to progress, and surfacing results at regular intervals to the whole team (including stakeholders).
Think to yourself:
could your dev/project teams benefit from a daily or bi-daily catchup meeting?
when you have design or project meetings, do the wrong people hog all the attention?
do you need to draw a distinction between various stake holders in a project?
could your team benefit from an iterative process, where "releases" are done frequently (i.e. every 3 or 4 weeks), and bugs and features are carefully prioritised against each other by the product manager?
The smallest team we have that uses something scrum-alike consists of 3 devellopers (2 full, 1 part-time), the stakeholder and the scrum-master ('secretary'). It works very well and we are planning to switch other small project teams to this method soon.
There are some 'points' you have to keep in mind:
We have the project status in an excel table under revision control, that is updated at least after the very short daily meeting.
The review and planning meeting is scheduled biweekly on a given day and will not be moved until all participants agree.
In all metings we break down the tasks from backloglist to smaller ones of max. 2 days of work, depending on the task type (concept, prototype, product etc). This proved to be the most valuable means to get reliable estimations!
If the stakeholder needs an status update or needs to adjust priorisation he can have a look at the excel table and change it, so even if he's not participating the planning meeting he has enough impact on project devellopment
The most important influence on management style is that you have evidence on what a given change would cost and what you can achieve until a given date (thing of a release date or a fair trade).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What approach did you take to describe the benefits of SCRUM to clients / business units who do not have a technical background? Please list any analogies you thought were useful. Finally, how did you address the concerns that the Waterfall camp had?
I basically go around about risk reduction and ROI, since these are the main things people at the higher management level care about.
Using a incremental process significantly reduces the risk of wasting money on something that's not gonna be useful, because the customer helps steer the product development in the right direction through series of planned feedback cycles. The #1 reason for project failure according to the CHAOS research is lack of customer involvement. So why not use a process that eliminates that risk?
Also, with a incremental process you start delivering something in a much shorter time than when using a waterfall approach, which effectively increases the ROI (return on investment), since the customer starts benefiting from the product after one or two months, instead of waiting 6 to 12 months in a typical waterfall project.
You can also mention improved customer satisfaction, team self-improvement and self-management, which reduces the administrative overhead, improved employee satisfaction.
An additional point is protection of investment - with traditional approaches, a system typically "ages" with time, its value decreases, and maintenance costs rise until it's no longer feasable to maintain it. With an Agile approach applied well, the code should be maintainable and extensible indefinitely.
Here is a good, short video on all three points: http://www.youtube.com/watch?v=OWvSnYjqOTQ
I would mention the benefits of focus. Because the guiding principle of sprints is functional focus and shipability, all details (e.g. ergonomics) need to be taken care of, whose fixing would otherwise be postponed under pressure in more global approaches. You don't have it all but what you have is solid. Non technical people appreciate that because it reduces risk from their point of view: it injects honesty and trust, together with interactivity, in the dialog with clients.