This post is part of a series about specifications, requirements,work items and test-cases in the field of Business Intelligence solutions. First part is about why I don’t want specifications and second is about how to write good requirements. This third part is settings the focus on work items before jumping to the test-cases to validate with stakeholders.
I’m always expecting that the whole team has a good understanding of the business we’re working for (even and especially when it’s a really complex business). The main reason is that it reminds them that our goal is to deliver working software to someone who expects specific benefits from using it … not just deliver a software corresponding to some specifications. To gain this good understanding of the business, everyone need to read (and understand) the requirements.
The key question is “Why do we write work items, if everyone is aware of the requirements?”. The answer is really simple, if you just have a problem, you can have many ways to solve it (probably many poor solutions but some great). First reason to write work items is to help the team to go on the same direction.
What are work items in this case? They are the solution, not the problem. This solution must be debated with a maximum of team members to be sure that we’re covering all the aspects of the problem. It’s what I’m naming the design. I’m not expecting to have interactions with business stakeholders during this phase, it’s not their role to validate that I’ve a good solution because (at this moment). They will probably not understand what they will effectively receive and should be their unique concerns (the what and not the how). This validation from stakeholders or end-users is for later during the writing of test-cases.
The design phase is not something with a clear start and clear end. It’s something that is starting during the reception of the requirements and is on-going until the end of the implementation. Anyway, you should have a good overview of your final design before starting the implementation.
At the end of this “main” design phase, we need to write the target solution somewhere to be sure we effectively implement what has been debated (No, just a picture of the whiteboard is rarely a good idea). This is a good idea to write down ou design in case we need to adapt it. Indeed if this design is written somewhere, we’ll clearly see the impact of our changes (what to re-do, effect on planning, …) . But also what has been poorly taken into account during this initial design phase … it’s usually an excellent lesson-learnt.
Until now, I’m speaking about a design and not about work items. What’s the difference? Work items are a decomposition of the design. The design is unique, work items are many.
When the team knows what should be done (the solution/the design), we also need to separate the work between the different team members. With one big document describing the solution, it would be a pain. To overcome this pain, I’d recommend to create some work items to subdivise the work to be executed by different resources and indicate the relations between them (precedence, …).
In order to achieve this, I’ve a personal rule: no work item will require more than 40 hours of implementation’s work (dev + test). If at any moment this rule is not validated, the work item must be split (It could be during the design, during the development or during the testing).
But it’s not so easy: We also need to be able to decide that a work item will be discarded due to a lack of time to implement it or a ratio cost to implement versus added-value too low. To achieve this it means that we can’t split the work between layers (database, etl, cube, report). If we need to build a dimension, I can’t split the work by layer and take the risk that we decide that we’ve no time to implement the ETL when the cube, database and reports are already “done“. We always need the implementation in all our layers or this new dimension will be pointless! So don’t split work items by technical layers.
Another good reason to avoid the split by layer is the lack of responsibility of the developers when the work items are expressed this way. Even, if the team has made an amazing job during the design phase, it won’t be perfect. We’ll meet unexpected issues (data quality or technical) and we’ll need to change our plans. When you’re dealing with the dimension from A to Z, you know for sure that any tiny problem during the ETL will create bigger issues during the implementation of the cube. So you need to fix the issue in the ETL … even if it was not initially described in the design. When splitting by layer, it’s really easy for the developer to not care about a tiny problem (to keep his personal planning) and let the next layers fix the issues. It will drive you to a poor solution where all issues are fixed in the last layers with tricks … not something that you’d like to maintain.
What’s a work item? It’s a small part of the global design, that can be implemented in less than 40 hours, discarded of the scope, and that will give a business value to the end-user when implemented.
What about a deployment to QA, a code-review or a refactoring? Are they work items? Not really. Naturally, if you don’t deploy, your solution is pointless but it doesn’t mean that it’s really part of your design. So it’s not a work-item but a task. And the script to deploy? Again not a work-item because it won’t directly give some added-value to the end-users and you can’t really discard this. So again it’s a task not a work-items. Tasks should not be discussed with the end-users (and surely not validated) but must be included in the planning.
Back to the work-items, what does it look like? Our work items are usually entitled:
- Create a new dimension D
- Add attributes X and Y to existing dimension T
- Build a hierarchy Z on existing dimension U
- Create new measure-group M and link it to dimension D and T
- Create new report “M by X and Y”
Sometimes, with our experience, we can split a work item into two distincts work items with essential attributes of the dimension in the first-one and some nice-to-have in a second. It will be easier to discard or post-pone the second work-item. But, that’s already an advanced level.
Then there is the description of the work-item and it’s usually where the things are becoming less straightforward … especially for really good developers. The usual problem with poor work items is not in how many we’ve, rarely their duration, and neither on their title but always in the content.
Poor work items are usually too detailed. They don’t write the solution at the conceptual level but at the logical or physical level. Most of the time, they are doing this to help their teammates … but it’s just the opposite that is happening.
An illustration? Surely! If your master data solution has two distinct fields first name and last name and you only need one field name. At the conceptual level, you’ll express that you’re expecting a unique field being the concatenation of first then last name separated by a single space.
Note that I never said if it should be done at the ETL level or in a view just before the cube. I have not explicitly written how to perform the concatenation! It would have been easier for me to write something like
first + ' '+ last … except that if the fields first name and last name are not trimmed in the master data, no one would trim them. Why? Because it was not requested! It’s so detailed that it would be too easy for the implementer, to say, I just applied your formulae and it doesn’t work, not my problem. Or even I thought that you specifically wanted to not trim them! Stay at the conceptual level, explicit the result that you want to achieve and not the how-to. If the developer is not sure about the need to trim or not, he will ask the question if you stayed at the conceptual level not if you explicitly requested to do a
first + ' '+ last.
Keep in mind that you cannot develop a whole solution without a few bugs. When you develop we’ve a few lifeguards such as a compiler and a few manual runs … writing detailed work-items is just denying this evidence and telling to others, “take a look I can develop a solution bug-free without a compiler and testing” … everybody knows that you’re wrong. Stay at the conceptual level.
If most of your work items are tasks in disguise, then the development process becomes task-focused (doing things) instead of delivery-focused (creating value) … and that’s usually my root issue with poorly written work items.
How to help the juniors without going to deep in the work items?
- Before they start to implement, ask them to explain how they will implement the work item. Don’t be too rude with them, keep in mind that you’re asking them to code on a whiteboard (without compiler, …). It’s difficult but at least, you can point them to a few possible issues and especially be sure that they have understood the work item.
- During the development, review each couple of hours their code with them. Ask them to explain what and why they are making these choices. Propose alternatives. Let them make their own choices.
- Write the tests in parallel of the development and ask them to use the tests during the whole development process (not only at the end when the whole development is done) and discuss any divergence between the code and the tests.
You should notice a few constants in the three suggestions:
- don’t do their job
- put them in front of their responsibilities: don’t make the choice for them!
- work in parallel, not ahead or after … with them.
Who should write the list of work items? I’ll give two answers to this question. At the beginning, it’s important to make an excellent work when creating the work items. By creating, I mean to decide if it’s one or two or three work items, check the precedence constrains (and avoid loops) and give good titles to these work items. From my point of view, it means that most junior team members won’t be able to do it. If they are, I’d strongly recommend to give them the senior adjective!
This is not a full-time job. If you’ve someone in your team writing work items during days, something is wrong in your process. It usually takes a couple of days of work to write work-items to implement in a couple of weeks. If you’ve a huge team, consider to have several writers but it’s really important that they have a good overview of what others are writing. I’d also recommend to consider to not have one dedicated resource to write the work items, the job-owner must change at every release … minimum. It’s really important that senior implementers keep their hands in the code and do their part of the job by coding … not just by reviewing code and writing work items.
But finally, work-items are alive and they must be regularly updated, reviewed and sometimes discarded. Every team member has the right to propose an adaptation and is responsible to update a work item, not just the initial writer. Every update must be internally debated with a maximum of team members and the initial writer.
You can use the work items in your discussions with stakeholders. It will be your unit to discuss what must be postponed or discarded. If your work items are described with too technical terms, it will be difficult for your stakeholders to discuss at this level … another good reason to stay at a higher level.
Keep in mind that discussing on an artefact to gain a confirmation that it must be prioritized or not is not the same as asking for a validation of the content of the work item. I stated before that work items shouldn’t be validated and I hold on … test-cases will help us to confirm with stakeholders if our design is correct or not! and it’s the scope of the next blog post.