modelling grocery orders, that can be split into multiple short orders
Your model is almost there for your stated purposes, so as I suggested in comments Picks doesn't need too many fields to capture the basic information you need to both accomplish splitting an order to different people, and tracking when/how it was completed.

While I mentioned the basics above, what you also really need are tracking/audit fields. With these you can actually monitor the status and recover history of who picked what and when. I'd suggest process audits and system audits. With both you can track issues with the software solution and your business process (allows some basic support for things like connectivity loss of scanners in a warehouse, system down etc.).

OrderID INT NOT NULL
StaffID INT NOT NULL
ProductID INT NOT NULL
ItemRetrievedFlag bit NOT NULL
ItemPickDateTime DATETIME NULL
InsertSystemID INT NULL --something like a barcode scanner device ID
AuditInsertDate DATETIME NULL
AuditUpdateDate DATETIME NULL
UpdateSystemID INT NULL


With a table like this you can retrieve order fulfillment history as simply as:

SELECT *
FROM Picks
WHERE OrderID = X


The query above gives you all recorded activity for the order, but it may not tell you what state the order as a whole is in. You should also have some kind of an OrderTracking table(s).

OrderID INT NOT NULL
StatusID INT NOT NULL
StatusDateTime DATETIME NULL
OrderTotalRetrievedItems INT NULL
OrderTotalItems INT NULL
AuditInsertDatetime DATETIME NULL
AuditUpdateDateTime DATETIME NULL
AuditUpdateSystemID INT NULL


You may find that with a consistent order fulfillment process you can instead dedicate columns to the status, but this pushes you into an update pattern instead of inserts as orders move through the process. If you keep a single row per status change you can more fully Denormalize your design.