Design
Big design and requirements upfront results in a lot of unused work and waste. AgileData Design helps us gather reqiurements and design thinsg in smaller chunks.
Information Product
Concept of an Information Product
An Information Product is an approach to describe a subset of data, analytical and visualisation requirements in a way that the business stakeholders can agree what they will get and the team can understand and deliver it in small iterations. I often articulate...
Information Product Canvas and Brief
The Information Product Canvas and the Information Product Brief are templates we use to document and share the definition of an Information Product. They are designed to provide a common and shared language which enables the Information Product boundaries to be...
Information Product Canvas Areas
The information Product Canvas is divided into 11 areas, each is designed to articulate a subset of the information requirements in a way that we can quickly capture these requirements and we can articulate them using a shared language. The areas can be grouped into 3...
When to create or iterate a Information Product canvas
Like a lot of artefacts you create and update as part of your AgileData WOW, the Information Product canvas and brief is updated multiple times as you progress through the delivery process. Each time more detail is added as you discover and document it. There are five...
Information Products relationship to data and code
One of the questions about Information Products I get asked a lot, is what is the relationship between an Information Product and the data or the code it relies on? DORO — Define Once, Reuse Often When we start working in the data domain we should be aware that data...
Information Product Anti-Patterns
An anti-pattern is a common response to a problem that looks like a great idea but usually ends up making things worse. An anti-pattern doesn't mean it will also fail, but it does mean it is higher risk and so you should be cautious when using it. Some examples of...
Information Product FAQ
Does an Information Product have to be delivered in a single iteration? No. If you are using a time box pattern for your iterations, aka a Scrum centric approach, I have found that three week time-boxed iterations seem to work best for a team when they are starting...
Personas
Concept of a Persona
The concept of a Persona A persona is a model of a fictional character that represents a user or customer. Personas are based on research about the target users or consumers, they are usually given a name, a picture, and a description of their characteristics,...
Persona Template
AgileData Personas We can use the same common language to identify and differentiate the group of people we are developing an Information Product or a data platform feature for. There are a set of typical personas we see in the Data and Analytics domain: Public...
Persona Template Areas
Persona Template Areas The Persona Template is divided into 12 areas, each is designed to articulate a subset of the persona demographics in a way that we can quickly capture these and we can articulate them using a shared language. The areas can be grouped into 3...
Persona Frequently Asked Questions
Persona Frequently Asked Questions Do you have to add an image or icon to the Persona Template? No. Using images to visualise Personas is a little contentious in the product domain. An image in a persona template can be useful in a few ways: It helps to humanise the...
Prioritisation
Concept of Prioritisation
Multitasking is the problem, we should focus on one thing at a time Data teams should only work on one thing at a time, but the problem is they often don’t know what the most important thing is. Stakeholders know the business outcomes they need to achieve, but they...
Core Prioritisation Patterns
Eisenhower Matrix The Eisenhower Matrix, also known as the Urgency-Importance Matrix, is a simple two-by-two matrix that helps prioritise work based on their urgency and importance. Work is divided into four categories: Urgent and Important, Important but Not Urgent,...
Fixed Mindset Prioritisation Patterns
There are a number of popular fixed mindset prioritisation patterns. MoSCow The Moscow prioritisation pattern is often used to prioritise tasks, features, or requirements in software development. The pattern consists of dividing tasks into four categories based on...
Problems with the fixed mindset prioritisation patterns
There are a number of problems that come with the use of the fixed mindset prioritisation patterns. The definitions of the prioritisation categories can be ambiguous and open to interpretation, which can lead to confusion and disagreements among stakeholders....
AgileData prioritisation patterns
There are a number of prioritisation patterns we have found in the agile and product domains which we have proven are useful when used to prioritise work in the data domain. We use the Information Product Canvas and the Data Platform Press Releases as the inputs for...
Levels of Prioritisation
When looking at the AgileData patterns for prioritisation you can see they are all based on prioritising Information Products based on the Information Product Canvas template or Data Platform Features based on the Data Platform Press Release template. It would be...
Prioritisation Anti-Patterns
Delegated stakeholders Stakeholders are busy people and they may try and delegate their attendance at the prioritisation workshop to somebody that reports to them. But while they will delegate the attendance, they often won’t delegate the decision making authority....
Self Organising Team Prioritisation
In an AgileData Way of Working the AgileData team are responsible and accountable to prioritise the work of tasks that are to be done. They are focused on the operational and personal levels of prioritisation. AgileData teams are responsible for prioritising tasks to...