How to establish a product Discovery Journey?

Most of us are working on solving some pretty hard problems, and it usually ends up taking some fairly complex systems in order to power these solutions. Product Discovery defines what should be built – and why.  Collaboration Is Key.  We are in a big hurry to push something out there in order to learn what works and what doesn’t; yet we don’t want to release something that’s not ready for prime time, and risk hurting our customers and damaging our brand. we need to simultaneously learn fast and also release with confidence. How?

Storyboarding - Would you be willing to be this collaborative when creating your backlog?

A storyboard is a sketch of how to organize a story and a list of its contents. Storyboard provides an ideal platform to create user stories and spark conversation in a format that is much less taxing than a wall of text. Use it when creating your backlog.

Scrum Epics (Themes and User Stories)

Some basic terms but sometimes it is very helpful explaining those terms again. So what is an Epic? whats an epic vs. user story and theme? and more..

Dealing with scope creep in agile projects

Scope will change and probably SHOULD change, to increase the likelihood of delivering business value to the customer. This is the same whether you are using Agile or traditional methods. The question is how do we react to this change?

Why can’t I divide large chunk of work into smaller ones?

How does it look like when a Scrum team does not understand the techniques, or even the value of splitting large chunks of work into smaller, working software chunks? What is the risk in not dealing with this issue fast enough? What can we do about it besides simply teaching the techniques? and why?

100% of the times when we are engaged in an Agile implementation inside an organization, we hear developers say -- and mostly this comes from team leaders, that it's impossible to divide big chunks of work into smaller ones (it may be dealing with large user stories or the technical aspect of splitting user stories to tasks, or other variations of the same slogan: "we can’t divide it to smaller portion”). Not only that, it is often assumed that large technical assignments cannot be divided into smaller ones. It’s a ”one hundred percent thing” - At the early stages of the implementation the thought that this is actually impossible is very common.

The absence of this skill, the mindset or understanding of the value in splitting large chunks of work into smaller working chunks is one of the painful issues that encourage and build resistance inside Scrum teams. We need to deal with it. Because resistance, if left untreated, can get out of hand.

It come in a lot of shapes, colors and forms, For example:

"The sprint should be one month since we will not be able to see anything working sooner, it’s plain impossible"

"Splitting to small chunks may work for existing code, but not for new features"

"Splitting to small chunks may work for new features but not for existing code"

"It is irrelevant when it comes to bugs"

"You can't do it for a research assignment"

"Our server side is more complicated than the GUI side, which is why they can do it. We just can't even if we would want to"

"Our GUI side is more complicated than the server side, which is why they can do it. We just can't even if we want to"

"UX is different. You can never do it"

"I have nothing to say on the daily anyhow – it's too big a stop"

"Experienced developers can and should have a backlog of large issues instead of wasting our time with small user stories."

"Its too much testing anyway, it’s a waste of time."

"Technically it cannot be split… whatever the merits, the business side will not be interested anyway."

"The Sprint was delayed because we can't split these stories, it's not doable"

"There is nothing to demo this sprint"

"Of course one could always split them into several so called "technical stories", but they are, with the exception of refactoring spikes, a big no-no in Agile, aren't they? "

(http://pm.stackexchange.com/questions/2316/how-to-handle-user-stories-that-cannot-be-split-and-do-not-fit-even-a-30-days-lo)

"In fact, the last 6 months, I've been working on a project where the entire point is for customers to notice no difference (platform migration)". http://pm.stackexchange.com/questions/2316/how-to-handle-user-stories-that-cannot-be-split-and-do-not-fit-even-a-30-days-lo)

It may even look like an active, strong emotional resistance toward the coach or toward technical managers in the organization. I found that team leaders who possess less technical skills, or who are less confident about their skills, or are less experienced as managers, often provided very dramatic or deterministic examples of these types of statements, to the point of ridiculousness. This behavior itself is very dangerous to an implementation and to the team mindset we wish to acquire.

I think the problem lies with these team leaders’ inability to immediately understand how to divide big chunks of work. This threatens their core professional image as software developers and poses a real threat to their confidence regarding their abilities as skilled developers.  The resistance can be very strong, and as a coach you know that you have to face these issues and you need to get those developers from the theory the practice as fast as you can.

We all know that learning to divide into smaller user stories, and from user stories to tasks, takes time. It's not an easy thing to learn or to get used to. It truly is hard for them. They need to both learn the skill and to understand the value. We need to provide all the technical and theoretical assistance needed and do it fast.

While this issue can definitely be hotly debated, the fact of the matter is that there are lots of ways to deal with large stories. Field experts have written extensively about it already.

So what can we do about it in terms of mindset and resistance?

1.       First, identify and acknowledge the smell. "we have an issue with dividing big chunks of work into smaller ones"

Don’t ignore it and don’t assume team leaders and/or developers will overcome it by themselves or just by reading an article. After all it’s a craft they need to learn and it takes time and requires the proper support.

2.       Assign a technical mentor – someone who could get his hands dirty and help figure out patterns of splitting. Someone that can be available for a long period of time and trained for the craft or knows how to do it already. It may be a technical lead, CTO, Component Owner, whoever the team respects enough on a professional level to allow him or her to "step into their territory" without feeling threatened, instead feeling safe enough to cooperate.

3.       Teach the techniques.

Explain the value of dividing big chunks into smaller ones: early feedback, higher quality work, delivering business value, etc.

Teach both the business side and the technical side, explain the value and the specific techniques out there.  

It's better to do so using a real backlog example.

Here are some links for further reading on techniques of splitting big work into smaller chunks.

http://www.roojoom.com/r/1757#/trek?page=1

http://www.roojoom.com/r/375#/trek?page=5

4.       Invest in the product discovery and planning sessions so that developers will have more small "ready" stories to generate in the first place.  

Make sure that during the ongoing discussions, as part of a discovery process or planning session there are people there who have the skill and those who lack it. The team discussion will expose those less skilled to the craft we would like them to acquire. There is nothing like ongoing real exposure to practice that is relevant to what you are going to work on next. It much better than a big chunk of training.

5.       Engage other developers, who have experience in breaking large chunks of work into smaller ones, in group discussions.

6.       Have a hackathon. Yes! A hackathon can have an amazing impact on this issue. It is fun, goals-oriented and requires presenting working software in a very short period of time. I will write a separate post on this matter, but suffice to say that having attended several hackathons in the course of my career has made me realize what a powerful tool this is for delivering this value precisely.

Using Use Cases.

What is a use case? How is it written? what's the difference between use case and workflow, or requirement or process? How is it used in agile? And what’s the deferent between use case and user stories? All of these and more in the following Roojoom. 

Enjoy.

Using diagrams with agile development

In agile development there diagrams too. “In today's world of agile delivery and lean startups, some software teams have lost the ability to communicate what it is they are building and it's no surprise that these teams often seem to lack technical leadership, direction and consistency.” Using diagrams have a good place in helping us collect and understand requirements as well as design our next development steps. They should be used as simple as possible and as a powerful tool to enable communication and collaboration of key information.  And there are a lot of them we can use.

Feature Injection

“Feature Injection is a business analysis process framework that allows teams to exploit the value of the traditional business analysis techniques in projects involving frequent iterative deliveries. It focuses test-driven-development and behavior-driven-development on delivering business value and ensures that a team only builds features and projects that deliver value, avoiding the wastes of scope creep and just-in-case code.”

backlog priority workshop - snake approach

In this project we had just come out of a couple of workshops to create a backlog of stories. We got together with the main stakeholders with the objective to create an ordered backlog. 

learnning scrum and Product Backlog exercises for teams

Different Approaches for Product Backlog Grooming

"The purpose of backlog grooming is to keep the product backlog up to date and clean. Scrum doesn’t prescribe how you should do backlog grooming, and different approaches are used by product owners and teams to do this." - Ben Linders

User stories Business Value

Although it may look easy user story business value might be really hard to measure. Where do we need to start, do we need to assign value to tons of small user stories ending up with lots of waste? What are the problems with assigning business value? How do we know the business value? And how do we assign it?

User Stories: How to write an effective user story? @BAEXPERTS

Story Points

In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort. this roojoom explains this concept and, do we do it? whats the relation between time estimate and user stories sizing? and how do we scale?

Don`t just ship software, make an impact! - Impact Mapping.

“Impact mapping can help you deliver projects that make an impact, not just ship software. It is a strategic planning technique that prevents organizations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better road-map decisions.” It is a mind-map grown during a discussion facilitated by answering the following four questions: Why are we doing this? Who will be impacted by it? How should our actors' behavior change?

Unfinished Work at the End of a Sprint?!

How much unfinished work should be allowed? As little as possible and yet, how do we handle unfinished stories or tasks? Here are some tips and practices collected from around the net.

T - Shirt Sizing user Stories

The Scrum Framework itself does not prescribe a single way for the Scrum Teams to estimate their work. However T-shirt sizes can be a great way of becoming accustomed to relative estimating. (XS, S, M, L, XL, XXL, XXXL) The primary advantage to t-shirt sizes is the ease of getting started. I really like this method although there are few more other good sizing methods we can use.

Low Hangigng Fruit Principel in Agile

A commonly used metaphor for doing the easiest or simplest thing first.  Easy-to-implement features that provide significant value. However, there are usually only so many low hanging fruits, and once those have been "picked,"you must put in  effort in other places to achieve results.

Elephant Carpaccio Exercise

The Elephant Carpaccio exercise was invented by Alistair Cockburnis and it is a great way for software people to practice & learn how to break stories into really thin vertical slices. It also leads to interesting discussions about quality and tech practices.

Introduction to Scrum Basics in Less than 10 Minute - My collection Favorites

There are so many short, less than 10 minutes scrum introduction videos. Here's my favorite collection to choose from to learn or train for the basics of the scrum development framework.