Interview Questions for Business Analysts and Systems Analysts


Recent Interview Questions | Search | Subscribe (RSS)

?
INTERVIEW QUESTION:

What is the Scrum method?

Posted by Chris Adams

Article Rating // 58577 Views // 9 Additional Answers & Comments

Categories: Systems Analysis, Agile Methods, Roles and Responsibilities, SDLC, Process, and Methodologies

ANSWER

Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the development of information systems.  The Scrum method brings a small team together to work on a specified set of features over a period of usually 30-days or so (called a sprint).
 
Both the term Scrum and sprint are borrowed from the sport Rugby.  A scrum is where the two teams are engaged in a huddle to begin play following a period where play has been stopped.  The fast moving period of play from the point of the scrum until play ends again is called a sprint.
 
The Scrum method starts each sprint with a kickoff meeting (a period where the entire team comes together).  The kickoff meeting lasts a full day and the features of the system to be developed are discussed.  The outcome of the kickoff meeting is a set of features that will be developed over the sprint along with estimates of how long the analysis and development of each feature will take.
 
In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested, Refactored, and Documented. If this life-cycle is not fully accomplished during the sprint, perhaps due to an initial underestimation of the time required, the feature will be pushed to a later sprint.
 
Following the kickoff meeting, and throughout the duration of the sprint, each day is started with a short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up meeting).  The purpose of this meeting is for the team to discuss what they accomplished the day before, what they will accomplish over the coming day, and to raise any obstacles that they have encountered that may impede progress.
 
One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size.  Most Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.
  • Product Owner – identifies the features that will be included in the next sprint and set the priority of each.  This is typically a high-level stakeholder in organizations where a true Product Manger/Product Owner role doesn’t exist.
  • Scrum Master – acts much like the project manager.  While the Scrum Master does not micro-manage the teams deliverables, this person ensures that the sprint is on track and enforces the key rules that guide Scrum such as; no new features can be added to the sprint once it is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint.
  • Team Member – unlike traditional software development methods, in Scrum there is little separation of duties between team members.  Each team member may fill the role of analyst, designer, coder, tester, and documentation writer. 

RATE THIS TOPIC

ADDITIONAL ANSWERS / COMMENTS

Ravish posted on Tuesday, July 13, 2010 8:17 AM
The framing of the article is perfect. This kind of information on SCRUM is not easily available.
In my project, we follow the SCRUM method and follow the above said approach, but out team is like 12 people at the SCRUM Meeting.
Ravish
Mark Wavle posted on Tuesday, July 13, 2010 11:02 AM
I would suggest a few tweaks to this very good article... Some details provided are not prescribed in Scrum, but are what some teams choose to implement.

For example, the length of a Sprint is not always 30 days - each team defines how long their Sprints will be, the most common lengths being 1 week, 2 weeks, and 1 month. For the purposes of this article, the specific length is unimportant as long as you realize that it is a fairly brief "timeboxed" development period.

I agree that the number of people on the Scrum team should be carefully considered, but I have heard it should be no larger than 10 to 12 before you consider splitting it into multiple, smaller teams.

Overall, this article does a very good job giving a quick overview of Scrum. Thanks for posting it!
Mark Wavle
zarfman posted on Friday, July 16, 2010 6:41 PM

Hi:

It was written: no new features can be added to the sprint once it is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint.

Zarfman writes: If the president of a company gets a call from his biggest customer who demands that some problem be fixed right now or he can kiss him goodbye. Guess what, if that team member is needed to solve the customer’s problem he/she is going to get pulled.

It was written: unlike traditional software development methods, in Scrum there is little separation of duties between team members. Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

Zarfman writes: This I do not understand. I seriously doubt that a coder/programmer can do the work of a skilled DBA. A skilled DBA knows the internal working of his DBMS. I suspect that a coder would not have that depth of knowledge. I doubt that an analyst et al is going to have the knowledge to implement FASB 157 without some outside expertise.

Regards,

Zarfman
zarfman
zarfman posted on Saturday, July 17, 2010 12:21 AM

It's zarfman again.

I was talking to a business associate of mine (a very talented DBA ) about the scrum idea that unlike traditional software development methods, in Scrum there is little separation of duties between team members. Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

He laughed and said thank God for Scrum. He said the it allowed him to live in a $500,000 house because he made a lot of money cleaning up the crap that coders/programmers produced who thought they knew how to design and set up a database.

Regards,

Zarfman
zarfman
Mark Wavle posted on Saturday, July 17, 2010 8:15 AM
Zarfman,

Hello, skeptic. :) It's obvious you don't like Scrum. That's fine.

I don't know if your intent was to help people better understand the Scrum methodology to prepare for an interview...but I'll take the opportunity to respond because these items may help someone in that situation.

Re: making changes mid-Sprint. Let's take an example of a 2 week sprint (perhaps the most common Sprint length). If a change is needed within the 2 week window:
1) Compare this to other methods like waterfall. How long would the customer have to wait in these scenarios? 2 weeks is comparatively VERY short.
2) The Agile approach actually makes these types of decisions much clearer. This is a capacity-based model where the customer is "paying" for a certain number of people to work a certain amount of time. Every 2 weeks, they together decide what business value they aim to deliver for the "cost" of the 2 weeks.
Thus, we can easily grasp the impact of interrupting the 2 week sprint - we know what was committed to that won't be done and it's much easier than the waterfall methodology to understand because the impact is sooner and the scope of what was being worked on at the time was smaller.

Regarding "little separation of duties between team members," I agree that this one is hard or unwise to fully implement in many scenarios. After 1 1/2 years on a Scrum team, I have come to view it this way:
- This is directional (aim in this direction), not destination-al (here is the absolute goal you must achieve)
- There is a beauty and strength in letting each team member bring all of their capabilities to the table. On my team, there is one developer in particular who asks some really great analytical questions...the kinds of thing a BA would normally ask. There are also times I bring up some technical design ideas that a developer would normally propose even though I usually wear the BA & QA hats. This is very healthy for the team and enables all of us to contribute to a great solution.
- Perhaps the most important concept hidden in this view is that we are focuses on trying to optimize the WHOLE process (reference Agile Manifesto: "We value working software...") rather than our own individual sub-processes. As a BA on a waterfall project, I might normally just be concerned with delivering the best requirements doc I can (my sub-process), even if the software ultimately delivered may not work right (overall process)...not my problem, not in my scope of control or influence. In Agile, the whole team owns the whole thing. That's not to say that I don't write nearly all the requirements, but it ensures my mindset is on delivering value to the customer in working software.
Mark Wavle
zarfman posted on Tuesday, July 20, 2010 4:56 PM
Hi:

Zarfman writes: I do have my own set of biases.

It was written: making changes mid-Sprint

Zarfman writes: I’m not sure if sprints are run in series or parallel or both. My point is the changes or work stoppages/required by upper management in one sprint may have an adverse effect on previous or perhaps subsequent sprints.

It was written: This is a capacity-based model where the customer is "paying" for a certain number of people to work a certain amount of time.

Zarfman writes: To me it would make a difference on whether the customer was internal or external. If the customer is external, paying involves invoices, accounts receivable and checks. If the customer is internal, the scrum group is simply a cost center or perhaps some form of internal cost transfer takes place.

It was written: Every 2 weeks, they together decide what business value they aim to deliver for the "cost" of the 2 weeks.

Zarfman writes: How is business value measured? Costs are usually measured in dollars.

It was written: This is directional (aim in this direction)

Zarfman writes: I’m not sure what this phrase means. To me aiming usually involves a target.

Zarfman writes: The reason that I mentioned FASB 157 in one of my posts is that FASB 157 is an intensely technical accounting problem. Unless, a BA or some scrum member is well schooled in accounting for fair value and cost within financial statements, it is doubtful they can make any significant contribution. In fact many companies do not have the internal expertise and rely on an outside accounting firm or their auditors.

It was written: Perhaps the most important concept hidden in this view is that we are focuses on trying to optimize the WHOLE process (reference Agile Manifesto: "We value working software...") rather than our own individual sub-processes.

Zarfman writes: What optimization technique and/or optimization software would Scrum or Agile use? Optimization typically involves working in N dimensional space. Not for the faint of heart or mathematically disinclined. Valuing working software is not the same as optimization.

Regards,

Zarfman
zarfman
septic sceptic posted on Friday, July 23, 2010 10:03 AM

It is written: "There is a beauty and strength ...." Oh please!

septic sceptic
ColemanTO posted on Monday, March 21, 2011 3:49 PM
I think a Rugby match might not be the best model for software development.

What's left at the end of a Rugby match? A winning team (and a losing team) and likely many minor (some major) injuries.

Hopefully, something more tangible is left at the end of a software development sprint.

I recently worked on an "Agile" project where we did a really good job of moving sticky notes (footballs?) and a really poor job of addressing the user's needs.

Maybe a better model would be something like an Amish barn raising...
ColemanTO
hemal posted on Friday, December 14, 2012 9:03 AM
also scrum works best when all the team members are based out of the same location.
i've worked in global teams where scrum model is adopted and the daily scrum meetings last 30-45 mins at least. In such scenarios scrum really is an overkill.
hemal
Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.

 



Upcoming Live Webinars

 




Select ModernAnalyst Content

Register | Login

Copyright 2006-2024 by Modern Analyst Media LLC