Prescriptive agile?

When working with new teams there's always a "learning curve" we all have to climb. So I tend to use the phrase "prescriptive start" when working with new teams. It's my way of letting a team know we're going to start with a small set of things the team must do. It's the basics and it will get us started. We can't learn a hundred new things, so let's start small. Let's get going and not try to boil the ocean.

Is it ok to call any form of agile prescriptive?

Definition: Prescriptive - giving exact rules, directions or instructions about how you should do something - from Merriam-Webster dictionary

Scrum lays out a specific set roles, events, artifacts and rules that bind them together. The Scrum Guide is only 16 pages, as compared to some other approaches. I know, I know:

• We do Scrum, but we don't find much use in having a retrospective... 
• We do Scrum, but we don't meet daily instead we meet on Tuesday and Thursday.
• We do Scrum, but...

You can find the full description in the The Scrum Guide.

If you are doing Scrum and not some variation of Scrum, but, then you know there are set of specifics that are part of Scrum. If you're not doing the basics you're doing "Scrum, but."

Domain modeling

A while back I posted a few modeling examples. Today's post is going back to that. This is the domain model. Again this model is for a simple library system which shows how concepts in a domain are related to one another. A box in the diagram is a term or concept. The lines represent connections and the labels on the lines show "how many" for the various relationships.

Cardinality illustrates business rules. As an example a Patron has one and only one account. And an account is associated with only one Patron. An account may have 0 to many fines on an account.


I've found that when using this model it helps to establish clear definitions of the key relationships in your domain. Some of the benefits of a domain model:

• Helps in understanding the problem space
• Creates a common vocabulary 
• Developers can understand the terms and relationships
• Shows what's in and what's out of the domain
• Allows the team to share with other teams when working together

I've used the term Visual Glossary for a long time - long enough I don't remember who said it. I've used it for a while. Either way - it's a visual glossary of the terms in the domain. Give it a try and see if it helps out.

Estimation - Musical Sizing

Do you want to have fun when you're working with teams. Is there a place for fun while working through a 2-day planning workshop? Maybe so...

Agile Requirements - Activity Diagram

If I had to pick one diagram that most people have seen and generally understand, it's the activity diagram. Sometimes called a process flow. The activity diagram can illustrate complicated flows. 

Agile Requirements - System Sequence Diagram (SSD)

In the Previous Post I talked about the System Context Diagram. It provides a high level view of a system and it's interfaces that make up the overall ecosystem for the product under development. The system context diagram is a static model, meaning it doesn't show interactions/changes over time. From a context diagram, we can create another model, the System Sequence Diagram (SSD) that will show interactions over time.