Requirements discovery

Requirements have a long history in software industry. We all have heard or read terms like: requirements definition, requirements management, requirements decomposition... tons of books, trainings and requirements themselves have been created for software all over the world.

Today, some of us may still have traditional requirements as a base of what we develop, some of us have just User Stories and work off of that. But throughout this article, I will use the word requirements to mean all of that input: traditional requirements, User Stories and whatever else form of "that-which-is-needed" we may have.

Traditional way of thinking about how requirements are created is that they are defined. That is, a clever person sits down and writes them down. In this article, I will try to make a point that they are not that much defined as discovered.

In software endeavours where the requirements are expected to be defined upfront, the person or the people who define them inevitably miss the factors that influence the way requirements are defined. There is no way to avoid this it is true no matter how knowledgeable and experienced requiremens author(s) are. Conversely, by refraining oneself from going too far with definition, the authors get a chance of opening their minds to factors that help them discover that which they have possibly never conceived otherwise.

Factors that help us discover requirements:

Direct feedback from users or stakeholders seeing the thing on demos, tradeshows, etc. This may be unfinished, unreleased work shown to existing or potential users, people funding the work and other stakeholders. They get a chance of influencing the direction for the product or its features before they will get to use it.

Direct feedback from users using the thing. This may be partial, staged roll-out of a bigger feature, provding basic functionality and then iteratively enhanced using that feedback. Check out the Walking Skeleton, if you have not done already. This feedback can be gathered directly or we can try to encourage the users to fill in surveys (good luck!) or use Google Analytics to discover behaviors and patterns.

Ideas from Sprint reviews. Sprint reviews are fantastic opportunity to look together at was done, exchange opinions and decide on the next steps for the feature. A good review may sometime trigger nice additions to what is being developed, but it can also result in the decision to change the direction more strongly, or to abandon something previously defined or developed.

Technical factors such as the contents of data being processed or displayed, existing code, existing UI/UX design or technical limitations can also fuel requirements discovery. This relies on the ability of requirements author to engage into a technical discussion with the team and their willingness to listen and take that kind of input into account. Yes, I mean it - if being a PO (or similar role) you developed the thinking that you can get away with just "defining The What" with no interest in The How, don't hope for big successes with the team.

Aim of consistency can also fuel requirements discovery by remind us how the different features in terms of user experience, UI or user-perceived logic should feel like one, consistent product, rather than like a bunch of random things developed by different teams.

Similarly, aim of purpose can remind us the intent for our product. Even as the feature set grows, the "one tool for everything" approach never pays off in the long run.

And last but not least, the Proof of Concept (or Spike) activity can shed light on what we can or cannot do and strongly influece the requirements at an initial stage.

To sum it up, we should open our heads to factors described above, and any other that we can spot in our work. We need to accept the fact that we are not able to do a good "definition" job sitting at the desk and staring at computer screen. Instead, go discover what's waiting out there. Then work on the definition for a while and then go discover again. This is how great features emerge.

Attitude is more important than skills

I was fortunate to work with a few development teams that were truly cross-functional. Every developer was able to perform several types of tests, build and deploy the product and develop code in layers of the product. Not many teams are like that.

More often than not, teams do specialize by skills like: frontend, backend, testing, etc. A cursory look at a job board makes it clear that the range of specialized skills is even broader: data scientists, Cloud maintenance engineers, DevOps, manual testers, and more. Developers are often hired based on these specialized skills - no surprise they may end up thinking they are there just to do one special kind of job. The risk that we are running here is the deterioration towards groups of uncooperative, though skilled, professionals.

This specialization, in today's world, is inevitable, but it does not have to be bad. It is extremely important to understand that specialization is a factor that influences the way the developers interact with each other and we can hopefully make it more transparent and use it to team's advantage.

Take me as an example - I have had much more development practice in backend than in frontend. Most of frontend designs I created were terrible. But if I were to re-use existing stylesheets and create a design of a sub-page that will be based on the current look and feel of an existing web service, I would be able to do that. Let me try to categorize my development skills a bit further:

• I'm skilled in backend - I'm really good at it, I'm able to develop elegant solutions quickly and I'm also able to mentor others.
• I'm comfortable with testing - I like finding ways to break things, I do not mind going through dozens of repetitive test scenarios. Testing doesn't give me as much fun as backend development, but I feel quite comfortable doing it.
• I'm weak in frontend - you know that already. But I am able to execute the simpler tasks, especially those that are based on existing styles and controls. If I were to work on a completely new wireframe, I would need some support from another developer and even with that it would probably take me some extra time.
• I'm lame when it comes to concurrency - I have rather academic knowledge of the topic, so even if I took much extra time to work on that kind of task and had the help from another developer available, I'm afraid I would let too many bugs through.

The fact that I'm weak in frontend doesn't make me blind and deaf to all frontend work that piles up in the backlog. If that were the case, I would be selfish and not playing fair with my fellow developers. But I can choose to be completely honest and transparent with my team, saying:

- Listen, this is not what I like most and I may not feel comfortable working hand in hand with other frontend developers, finishing their tasks quicker than me. But I am willing to work on this, because we need to be flexible as a team in order to reach our goals. I will need some help from our frontend experts. And please do blame me too much on how long it takes me to complete or if I stumble.

Traditional approach to skillset problem would be for a resource manager to draw up a skillset matrix, have everyone in a team tick off their skills and then assign goals so that people learn things. I'm not saying this method is completely wrong, it can be useful to identify situations we need to address, but look - even without goals for learning new skills most developers are able to do a range of things wide enough to produce a list of categories, like mine above.

Let's make the categories a bit more official. You can come up with your own categories and have more or less then four, but for now let's move on with the ones I proposed.

The drawing on the left serves just to depict the categories and the range of things beyond one's capacity (can't do), so do not pay attention to how much percent each category spans.

With categories suited for your team, you can ask all your team members to consider their skills for themselves and then act fairly upon it, or you can go further and, upon unanimous agreement, arrange a session to talk about each other's skills openly.

The goal is to develop an attitude, within all team members, to be willing to take up most work based on what the team needs to achieve, rather than on "what gives me most fun" or "what increases my self-esteem".

The Product Owner defines the backlog based on what the customers need. It is not their job to define the backlog so that different skillsets in the team are fully utilized. This is why the development team must be able to create a substantial level of flexibility of skill. The way towards it is not that much through analysis and goals as it is through the change of culture and habits.

Limit WIP

Although Scrum Guide does not mention this explicitely, it is an important part of sprint planning and the sprint work itself to limit the amount of Work In Progress. Let's look at this aspect in detail and consider some examples.

Without the notion of WIP, several team members may just start work on several backlog items, say 6 developers start 6 different backlog items. In practice, this apporach often goes together with the phenomenon of one developer working on a single backlog item for several days - either because they are too big for one person to complete them quickly or because they are too big in general. If the backlog items are too big, each developer may work on their backlog item even for the whole duration of the sprint. Now, there are some disfunctions in a team that does this:

Teamwork
Each developer is focused on their backlog item, so there is no really teamwork there. If at least 2-3 developers focus together on one backlog item, it fosters collaboration and gives people common aim. Developers who work together on one item are also more exposed to changes being made in the code, because nobody is developing in a silo.

Predictability
It is very difficult to say if the team is going to each the spring goal at any point during the sprint - everything is in progress, everything is assigned, but what will actually be Done - this is unknown almost until the very last day. With smaller backlog items and 2-3 developers working on each, a substantial part of sprint backlog is completed during the sprint, so it is much easier for the team to gauge what will be completed by the end of the sprint (at least the items that are Done now wil be Done at the end of the sprint).

Sprint planning
With silo work and big backlog items the team is bound to miss important aspects of the spring planning meeting. After all, a developer that is going to work alone on backlog item A for 10 days will not have much to say about his plan. On the contrary, if a few developers work on each backlog item and the backlog items are rather small (say, doable withing 1-5 days each), the sequence of work is becoming very important during the planning. The team will not plan to start the bigger backlog items late in the sprint. They will consider the order of sprint backlog and the order of their planned work during the sprint to maximize the probability of achieving the sprint goal. They may even notice that what the Product Owner desires is not achievable in a sprint - not because there is too much work to be done but because the sequence of work puts constraints on the delivery.

In a well performing team, there should typically be more than one developer working on a regular backlog item. The backlog items should flow quickly from In Progress to Done, because they are small and two or more people usually work on each. The team may choose to set official WIP and put it on the corkboard - no more than 3 backlog items In Progress at the same time. Or they may just pay attention to it without setting the official limit. Finally, a good Scrum Team will pay attention to defining and splitting the backlog items so that they are small. It is not enough that a backlog item is just doable within a sprint. Smaller backlog items give the team more flexibility in the way they plan to sequence their work and allow them to start work on next backlog items even near the sprint end.