Scrum Board and mixed goals

The Scrum Guide describes the Sprint Goal as a coherence that gives the Development Team a reason to work together during a Sprint, rather than on separate initiatives.

The Guide also advises that the optimal team size for this endeavor is between three and nine people, and that the team should have all the skills needed to craft a "Done" increment. 

How important has the Scrum Guide been to your team thus far? Has it been referred to often?

First, Scrum Guide says nothing about boards so there is no Scrum answer to this question.  A board is actually an artifact borrowed Kanban.  It is nothing more than an information radiator that helps to make information transparent.  In Kanban the board contained items that needed to be done and the columns of the board represented the workflow.  It was designed to show all the work necessary to take an idea to delivery.  Since it was originated in the car manufacturing domain, the columns represented activities that spanned many departments in the company.  And it's not unheard of for individual departments to have more detailed boards for the activities within their department where entry to the department board came as an item was moved on the organizational board into the department's column and exit from the department board represented moving to the next column of the organizational board. As Kanban was adapted for software delivery, it is quite common to have columns that represent all areas involved in the delivery. 

Scrum has adopted boards to represent the work being done by the Scrum Team during a Sprint that is needed in order to achieve the Sprint Goal.  Most common use is to have the Scrum Board represent the Sprint Backlog which are the items selected by the Development Team to be worked on during that current Sprint. 

The board you mention seems more like a Kanban board.  If it is beneficial to the entire Scrum Team, I say keep it. But recognize that the board is not limited to a single Sprint.   You could also introduce a Scrum Board that is used by the Development Team to radiate information on the current Sprint and progress towards satisfying the Sprint Goal.  

I want to also point out that User Stories are not part of Scrum.  They were borrowed from Extreme Programming.  Kanban did not use User Stories. It used activities such as the ones needed to keep a parts inventory for a particular station in the manufacturing line supplied. User Stories lend themselves well to knowledge based work so they have become largely used in Scrum.  You might want to consider having your wider board adhere to Kanban practices of flowing objectives across the board and the Scrum Board could be used to move User Stories.  But that introduces more complexity to the work.  Personally, I'd have a Scrum Board set up to show the workflow the Development Team uses to move work through their process. The columns would be consistent with subtasks that you would do.  Move the same item that comes from your Kanban board through your Scrum Board. 

Hi guys thanks for the previous answers. My concern then is,  how to define and increment in a sprint ? Is not what a crossfunctional team should be able to deliver ? Is it not the increment defined in the Sprint Goal ?

So let s make an example realistic, that does not sound very healthy to me.

1. Back-end have a goal , implement secuirty and authentication

2. Front end wants to deliver Data entry page

3. System Designa and UX research are investigating what s down the line for the next 2 sprints and various wireframe design.

What the consistent and defined goal would be ? How should the team define the Sprint Increment ? This is not a cross functional team and is not delivering just one increment but many.

I feel sometimes that the development team has a very to wide interpretation. I think this is the clash for me from the old idea of Team and on what a Scrum team should be. Enginering capabilities able to deliver a well defined increment.

Thanks.

My first reaction was that both #1 and #2 seem to need back-end and front-end work so how could either complete that work?  This sounds like a time that the Product Owner needs to order the items appropriately and work out a compromise with the Developement Team.  It also indicates that the Scrum Team is not owning their work as a team but instead want to operate as 2 different teams.  And it also makes me think that the reason the front-end team wants to do a data entry page is because the back-end team has already done that work.  Does anyone else see waterfall in that situation? 

#3 is something that I typically see being done as part of refinement. In fact, in many companies I have worked at or have knowns others to work at will usually have one or both of those areas working outside of the Dev Team and see it as part of Product Management so that those items are being provided to the Development Team as part of a refined story.  Although, the Systems Design part has always been a problem for me.  I have seen so many times that when a system design is handed to a development, when implementation begins the design will change based upon new findings.  So I feel the best system design will emerge as the development team starts to work on a problem and as such that is an activiity that should be done by the development team as they work on solving the problems put forth by the Product Backlog items. 

Hi @ANGELO TROZZO,

[1] Uses of Scrum 

Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:

1. Research and identify viable markets, technologies, and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
5. Sustain and renew products.

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.

As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily.

Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization.

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.

When the words "develop" and "development" are used in the Scrum Guide, they refer to complex work, such as those types identified above.

[2] In you case,

[A] First thing scrum suggest to have 3 to 9 members in a scrum team. So currently you have 13 members so you need to ask the development team to logically divide a 2 scrum.

One possibility: One product Owner and 1 scrum master can able to support both.

[B] As mentioned by others in this thread the team needs to work towards the sprint goal. 

[C] Please do the ground work before start the Sprints. Check which is suitable Scrum, Nexus, Kanban or Scrumban, etc. and identify based on your organization and your project needs.

[3] Reference

https://www.scrumguides.org/scrum-guide.html

https://solidgeargroup.com/en/how-to-apply-scrum-in-real-life/

https://medium.com/serious-scrum/7-reasons-not-to-use-scrum-480530e3e00a

Thanks.

Putting disparate groups of people together and calling them a team doesn't make them a team.

The points made about team size are relevant. Consider this image, which shows the increasingly complex lines of communication between team members, as a team grows in size:

This complexity would be unworkable for most people, so quite naturally they may look for ways to simplify it.

In the past, I saw teams of 9 or 10 people splitting into implicit sub-teams, to the extent that only some of them were working towards the Sprint Goal for a sprint, and it wasn't entirely clear who was or wasn't focused on that.

I know very little about System Design, so I'll just talk about UX (but I suspect the problems are similar, and could be solved in a similar way).

UX needn't be a hand-off that is done up-front and then passed on to front end and back end engineers.

Furthermore, it sounds like front end and back end engineers are focused on technical objectives, with little attention to what outcome this actually achieves. As such, I'm going to call them both teams, because it seems more representative of what you have.

Is it really success for the front end team if they build a brilliant data entry page and no-one can use it, because the back end team are focused on making the login functionality work, and therefore too busy to do some other supporting work, such as the data storage?

Is it success for the UX team if they design a brilliant looking design, but then it turns out that by the time it's built, engineers have had to make trade-offs based on technical capabilities? What about if end users then use it in a different way to what was expected, but the teams have already moved on, and there'll be no chance to iterate on that feedback in the near future?

Is it success for the UX team if they pump out designs that never see the light of day, because no-one has time to implement them?

An alternative way might be to give these people purpose and the space to self-organize into one, two or three cross-functional Development Teams; each of which would set itself outcome-focused Sprint Goals.

In this case, the Development Team would be everyone who develops the product (all kinds of engineer, UX specialist and System Designer), and the Development Team might also self-organize so that some members become more cross-skilled (T-shaped), and adapt to what is most needed, not where they are personally most efficient.

It's still likely that the UX specialist(s) in each Development Team would be spending more time looking ahead in a given sprint (doing proportionally more of the refinement), but it's also likely that the entire Development Team will become comfortable with more uncertainty, heading into each sprint.

A wireframe or design may be there, but the team might plan to build and release in a way that allows for more reversible decisions, and the UX specialist might observe data, or conduct user interviews in such a way that means they bring new insights to the team from the first days of the sprint. The Development Team might then replan its work (including a new design) in order to achieve what is most important.

Taking the separate goals you identified, perhaps security standards are added to the definition of "Done", and something that the Development Team agree to meet in everything they release, such that security never needs to be mentioned in a Sprint Goal or acceptance criteria again.

A better Sprint Goal that would unify the front end and back end engineers might be: "Enable only logged in users to enter the data."

An even better, outcome-focused Sprint Goal that would potentially also include the UX specialists might be "100 pieces of data are entered by logged in users".

This might focus the front end and back end engineers to build and release the most important functionality early in the sprint (and delegate the planned nice to haves until later). The UX specialist might then learn from data or by talking to users that the reason not enough users are entering data is that they don't know the page exists. This might mean work needs to be planned within the sprint to update the navigation menu, or provide a useful call to action somewhere.

Similarly if the problem seems to be that users have problems using the form, that might be a reason to prioritize planned UI improvements to that form as the next piece of work.