Skip to main content

What is a Scrum Development Team - 7 minute Guide

I have noticed in many places that are working on implementing Agile methodology a popular misconception around the question who are the Scrum Development Team.
Most people wrongly assume that it is the de facto developers who write the code and when I point out that it is not the case it is being met by dismay and skepticism.

"Developers are developers, who else can development team be?" I was told once in a such discussion, and the answers to that is hidden with in the Scrum guide

If one will go and carefully review the guide one can find the following definition there:
"The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint."
Take a note of the phrase "... rofessionals who do the work of delivering..." those are not only the developers who write the code but also the Testers who test the code, the BAs who taking care of Backlog items to be kept in tact and so on.
To support that understanding the following can be found in the guide as well:
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment
Again the clear pattern is emerging that the Scrum development Team is professionals of different trades that came together to create something new - a "Done" increment if you will.

But then there is a big question why we cannot find any mention of QAs, BAs, Developers (as pure code writes anywhere in the Scrum Guide?

The answer to that is simple enough because the whole idea of Scum is against it:
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person
Scrum is about working together as a group and allowing each team member to do its best to contribute to the successful delivery of the "Done" increment.

Why this definition is important?
In my experience it happens that QA and BA team members work effort are being forgotten during the planning and estimation of the Product Backlog items, and the focal point lies with the de facto developers. This approach results in inaccurate estimation and unsuccessful Sprints when the Product backlog Items cannot be delivered on time because of additional and accountable  work that was required to complete the specific increment.


Popular posts from this blog

Story Points estimation for Scrum with Fibonacci vs Shirt Sizes vs Linear - 7 minute guide

It is all began long time ago when Development Teams were constantly asked to provide estimate and they were having a hard time to properly face the task. Let's admit it, there are so many things that can change, happen, and simply go wrong during the development process that one can hardly expect a proper estimation of hours for each task. That why a relative estimation with Story Points came along. Story Points Estimation Its a different way to estimate the effort of the Scrum Development Team with-in Agile methodology, which means that instead of estimating hours of work the team estimates each effort relatively to other efforts in the project. Let's assume that a developer knows that specific 'Task 1' is much harder than another 'Task 2' it is hard for him/her to quantify that harder feeling in hours of additional work but it is possible to say that it much more work. This situation is being address by Story Points when each story point is

What is the velocity of an Agile scrum methodology?

Let's discuss some of the important measurements in Agile, and that is the Velocity of the Scrum team work. Based on Wikipedia definition Velocity is " ...the rate of change of its position with respect to a frame of reference and is a function of time...", which when transferred to the scrum world can be summarized as: The amount of work that the scrum team completed in a single measure of time - in a sprint. How we Calculate Velocity? Velocity is actually a very simple to calculate, it is done but totaling the number of story points of fully completed user stories from the sprint backlog. So if a current sprint included 4 user stories: 2 with 8 story points each, one with 3 story points and one with 32 story points. and by the end of the sprint the 32 one was not fully done the velocity calculation will be: 8+8+3=19 Note: the 32 story points are not part of the velocity calculation as this user story was not completed. What Velocity is used for? The v

7 Most Popular Test Types in Software Testing

Today we are going to return back to basics of software testing and discuss the 7 most popular test types that are being used in every software testing effort. Those different test types cover all the levels of the software to make sure that the final result matching the expectations from every possible angle. Here is our list: Unit testing Smoke testing Regression testing Functional testing Integration testing User Acceptance Testing Performance Testing Now let’s have a deeper dive into each one of those by using a simple example of an imaginary system that was created in order to manage warehouse activity including shipments, inventory and goods receptions from suppliers. Unit Testing This type of testing is usually performed by the developers and is covering the very basic development component. In this test developers are testing the straight forward functionality of a functional piece of code to make sure that it is performing according to th